如何来想,怎么去做(上)

来源:互联网 发布:数控编程薄膜按键开关 编辑:程序博客网 时间:2024/03/29 14:35

如何来想,怎么去做(上)

分类: android分析 工具 654人阅读 评论(0)收藏 举报

目录(?)[+]

假如你跟我一样,“有幸”进入了一个大team,又参与到android手机rom的深度定制的某个环节中,身处项目中代码链的最末端,那么我想,这些经验应该也对你有点用处。

 

工作的开始

       你工作的很大一部分是处理分派给你的bugs,这些bug大多数又是由于以下几个问题造成的:

1.        项目版本随着android原生版本的升级所引发的bugs,有的在过去就有,有的则是升级之后带来的。更糟糕的是,还有不少是旧版本中你添加的内容在新版本上反而不兼容造成的。

2.        平台商会出一个他们基于android所做的版本,我们通常的修改都是基于这个基线所作的二次开发。同样的,这个平台商版本往往也有很多稀奇古怪的问题。而且最要命的是,平台商的升级可比google勤快多了,每次升级之后都要重新拉基线,而你基于上个基线所作的修改又有不少需要重新并进去……

3.        除去上述两个大坑之外,剩下的多半是某项功能升级不完整或者是添加新机能所带来的问题。不过相对前面的救火工作而言,这个要更有挑战性,也更有趣一些。你想想,原本只能DSDS(双卡双待)的手机突然变成DSDA(双卡双通)了,上层也许感觉不出什么,但是底层的改动是巨大的。这就要求你重新设计一些新的机制来满足要求了。

 

也许你的工作内容比我所说的这几个要更复杂或者更简单一些。不过请放心,大体上你是逃不出“收邮件、发邮件、解bug”这个圈圈的。

 

修改前后的准备和归纳工作

如果你跟之前的我一样,每一次bug报上来就急匆匆的去解,解完一个又一个,一个有一个……你总会发现似曾相识的问题越来越多,你虽然解的越来越快,但是越来越烦躁——MD这跟生产线上糊纸盒子有什么分别?!

 

所以在项目前后对于模块的准备和归纳工作是非常有必要的。

要归纳什么

每个项目也许一直都有人在维护。但对你而言,你的提交修改总有结束的一天。当你预见到这个项目已经做得差不多了,而下个项目还在孕育之中的时候。就可以开始作作归纳总结了。


咱们不谈那些虚的复盘总结或者是项目总结报告之类的玩意儿。就说什么样的总结能对你之后的工作带来好处。


就我现在的经验而言,以下几样东西你最好是总结一下:

1.        这个项目中你负责的模块的基本架构以及与之前项目同样模块的区别

你所负责的模块可能只是这个代码机器中微不足道的环节之一,但是相信我,就算是最小的螺丝钉也有它不可替代的价值,更何况这颗螺丝钉也在不断的进化。

弄清楚你所负责的模块的架构,是你日后解决这个模块相关问题的基础之基础。也许你可以凭着经验跟log解决一些代码级的错误,但是涉及到android机制的问题则会越解越缠。在我最初接触这个行业的时候就是这样,直到我花的大量的时间去了解一些底层的东西以及所涉模块的概念。情况才有所好转。

然而这样还不够,因为google跟平台商的模块在不断变更,包名更换,类重组这种情况还好,如果遇到了某个逻辑被重新设计,那之前总结的经验就统统失效了。

所以,你最好每个项目结束后——至少每个平台项目结束之后都做个模块模型的总结。

 

2.        你提交的修改代码都有哪些,所解决的问题都各自是什

把你提交过的修改都抽出来,如果你用的也是git的话,我这有个写好的shell可以帮你做个整理。

[plain] view plaincopy在CODE上查看代码片派生到我的代码片
  1. #! /bin/bash  
  2.      
  3.     echo "+++++++++++++++++++++LOG forAndroid++++++++++++++++++"  
  4.     echo "+++++++++++++++++++++Write byguiyu+++++++++++++++++++"  
  5.     echo "____________________Patch forcommits_________________"  
  6.    
  7.        
  8.     echo "Please make sure the folder nameis the name of project"  
  9.     #create new document to leave the patchs  
  10.     name_of_doc=${PWD##*/}  
  11.     date=`date +%Y%m%d`  
  12.      
  13.     <span style="color:#ff0000;">Framework=frameworks/base</span>  
  14.     <span style="color:#ff0000;">Opt=frameworks/opt/telephony</span>  
  15.      
  16.     #[ -d ~/Patchs/$name_of_doc ] || mkdir~/Patchs/$name_of_doc  
  17.     #[ -d ~/Patchs/$name_of_doc/$date ] ||mkdir -p ~/Patchs/$name_of_doc/$date  
  18.    
  19.     dir=~/Patchs/$name_of_doc/$date  
  20.    
  21.     for folder in $Framework $Opt  
  22.     do  
  23.         cd ./$folder  
  24.         git log --author="<span style="color:#ff0000;">yourname</span>"> log  
  25.         echo "Your Commit are asfollow..."  
  26.         cat log  
  27.         echo "Totoly number is "  
  28.         Number=$(grep commit log | wc -l)  
  29.         #$i代指上一次输出结果  
  30.         git format-patch--author="<span style="color:#ff0000;">yourname</span>" -$Number  
  31.         #[ -d $dir/$part ] || mkdir -p$dir/$part  
  32.         [ -d~/Patchs/$name_of_doc/$date/$folder ] || mkdir -p~/Patchs/$name_of_doc/$date/$folder  
  33.         #mv *.patch $dir/$part  
  34.         mv *.patch ~/Patchs/$name_of_doc/$date/$folder  
  35.      
  36.         echo "Expolor your patchs"  
  37.         for ((i=1;i<=$(egrep commit log | wc-l);i++))  
  38.         do  
  39.             Num= grep commit log |  awk NR==$i'{print $2}'  
  40.             echo $Num  
  41.             #git reset --soft $Num  
  42.         done  
  43.         git status  
  44.         #N= grep commit log |  awk'{print $2}'  
  45.         cd -  
  46.     done  
  47.    

你只需要根据需要填上你自己常维护的模块跟你的姓名就可以了。

这个脚本可以把你提交过的内容根据日期跟项目名都导出到~/Patchs目录下。

这个备份至少能保证你会清楚这个项目里你都做了哪些修改而不至于在后来的工作中丢三落四。

别忘了在git log中对你的修改内容做足够清楚的备注,这样才能在之后的使用中不至于混乱。

 

3.        你所解决的问题怎么归类,是否有共性

一个模块上的问题会一直有,但是他们的类型是一定的。把所出现的问题归类,每一类的问题找出一个“最终理想解”就是你的任务了。

顺带说一句,找出一类问题的解决方案可以在后期极大减轻你的工作强度——譬如说,当你发现这类看起来非常难搞的问题其实是别的模块不完善引发的,那么在之后的工作中,这类问题完全可以处理为:

“请相关模块的同事看看,非常感谢”

 

4.        搞定跟你相关的其他资源

就一句话——一*定*要*跟*PM*搞*好*关*系。

谁用谁知道。

要准备什么

一定要清楚,我们不同于那些跟硬件直接肉搏的射频或者是bsp的同学们,他们手里拿到的板子多半是连框框都没有的EVB阶段产品。等我们开始调试或者merge代码的时候,终端设备基本已经成型为EVT甚至是DVT阶段。


因此我们有至少2周的时间来充分熟悉新的项目环境。不管是升级了原生版本还是平台版本还是增加了什么功能至少做到心中有数。


如果你之前的准备做得足够好,那么你现在至少已经清楚了这个新项目中所属模块中可能会存在哪些问题,哪些结构已经发生了改变,你应该怎么去修改。


很好,这时候上一个项目中存储的patchs就派上用场了。

在模块结构没发生太大改变的前提下。

[plain] view plaincopy在CODE上查看代码片派生到我的代码片
  1. Git apply –reject****.patch  

可以把你之前修改的大部分内容给并进去,少数的也可以手动调整一下。比起人眼merge来说省力一万倍。

 

如果很不幸你的模块发生了逻辑上的变化。

那么也不要太担心,因为你之前的功课已经做好。Google虽然爱调整,但是基本的结构还都存在,你把那些没改动的地方挑着git apply之后。再根据模块的结构在新的内容上添加patch吧。

 

顺利的话,你会在项目之处就把该留的接口留好,该修正的老问题修正。剩下的时间跟精力,可以用来应对后面一大波“新功能bugs”。

 

0 0
原创粉丝点击