项目开发总结

最近做了一个项目，项目中发现了不少问题，在经理的鼓励下作了一下团队内部总结，我把自己写的贴在这里，也算是这些年来开发生涯的一个小故事吧。

 

 

这几天工作比较闲，正好有机会好好反思一下开发smart-search时的问题。我的眼界有限，以下说出的观点不一定反应事实且对事不对人，权当抛砖引玉。

 

1. 过于陷于细节，反而不细节。做功能时，我们做的很细节，可以把每个功能点都基本实现；解bug时，我们可以把功能点实现不完善、有缺陷的地方很快的改正；我们看起来都是实现细节的高手。但是，一些很重要的点，我们很粗。这几天，我看了点mvc的东西，我越发感觉，smartsearch搜索这块，是可以用mvc的（虽然现在实现也有点mvc的味道，但是这不像是精心策划的结果）。还有，第一版本的smartsearch是根据用户名字不同域来产生特定匹配序列，后来发现这个做法缺乏灵活性，而且本身就有风险：不同语言组成的displayname是不同的，开发平台的人都知道一句话：“eat your dog food”，我们是程序员，但是却做了错误的决定去归纳语言的规则，这不是我们擅长的事情（因为后来听到junbo说他们有一个feature允许用户设置名字顺序后，我感觉犹如天塌了一般；而且这样也把uxc引入了一种语境，在做之后的版本时花了不小的成本给她们解释、沟通）。还有，现在代码中一些类，并不是设计良好的（指责单一，指责明确，接口明确等等），也许在刚开始设计它的时候并没有想好，但是就那么写了，随着项目的推进，它开始膨胀，变大，却没有挑战它，以至于后来，我们都宁愿忍受它的种种负面问题而不是改动它，更倾向于接受它是legacy问题的假设。等等。这些都是高于实现细节的细节，更像是设计上的细节，我觉得我们没有做好。

 

2. 对android平台掌握不足。譬如内存泄露，占用内存过高，对平台特性理解不深刻，ui实现中存在资源浪费，等等。。

    

3.交流不足或没有深度。在设计之初，Jerry问我关于数据库的事情（我之前搞过一阵子web开发），我现在看来，我当时的回答，也是拘泥于细节，什么通配符是？还是* 之类的，而不是从一种高度去解释数据库的概念，并结合以往相关的经验。也许是我经验不够，眼界不宽，不过这也是跟我没有能力将既有经验转换成一种更有价值的形式有关。譬如，我们做完smartsearch，那我们的经验不应该仅限于怎么做一个view，而是如何实现一个没有浪费且高效的view；不是怎么实现数据库搜索，而是除此之外还要知道在哪些情况下使用数据库会碰到问题，android平台的sqlite有什么样的特性，查询出来的结果集存在哪里，能存多少，有什么问题，等等；怎么防止内存泄露，不是说把所有涉及到context的地方都一股脑设置能null，而是什么是context，为什么要释放它，什么东西需要引用context，如何从设计上防止过度的context引用，如何使用内存分析工具；bitmap的内存使用状况；等等。这些细节，不但需要我们总结，而且需要总结到某一天我们可以清晰地解释给别人的地步。

 

针对以上我看到的问题，我提出我的一些解决办法（包含一些发散的地方），不对之处请尽管指正。

 

1. 做软件是件挺复杂的事情。既不是我们生下来就会，也不是我们解解bug，看些代码片段就会，需要我们学习理论-实践-思考—学习理论-实践…，循环往复。试问自己一个问题，你能否从0构建一个良好的软件。我问过自己，我的答案是不能。Smart-search不是一个真正意义上从0开始的软件，但是看它的核心逻辑部分，它确实有从0构建的味道。这一次的从0开始，我们做的不是很好，但好的是我们有教训。再试问自己一个问题，当你碰到一个难以捉摸的软件难题（设计/实现）时，在公司内，有谁能帮你？我的答案是谁也帮不了你，你只能靠自己，因为那段代码需要你来写。我自己做的不好，我曾经以为读完了大部分android 开发文档，我就会做android软件了，但是现在发现，我只是会一些android而已，离做软件还远。所以我决定重拾起经典《代码大全2》，来好好看看，什么才是做软件（前几天在家翻了几页，发现，在smartsearch开发过程中考虑不全的问题，在它里面已经提醒开发者去思考）。另外还可以主动参与一些开源项目来加强实践（不是所有的知识都能从phonebook中学到，但是反过来可能会用到phonebook中），举个例子，twitter的开发团队的github页面，总共公布了十多个开源工具或框架，我想这些框架绝不是都来自于twitter技术本身。技术人，需要实干，也需要眼界、交流、分享。

 

2. Android平台的问题，除了快速的查看文档、源代码，上stackoverflow去找答案，上google之外，我觉得应该加上一条，拿一部手机，没事就下点android市场上那些优秀的软件来用一用。

 

3. 好记星不如烂笔头。写写博客，写写notes，总结经验，发给大家让大家学习并提意见。有什么技术争议点，也心平气和的讨论。等等。

 

 

@同事A

我讲一个小故事供你参考：我的一个朋友，在国内一家手机公司做开发，当时他们3个开发接到一个项目要去做安全方面的软件，基本上从0开始做，他们3个人考虑了2周，都不知道从哪里下手，后来，公司安排给他们一个架构师，这个架构师来了之后，一步一步地把他们这个软件从需求到架构全部定义清楚。有一天他去问这个架构师几个技术细节，结果这位架构师却不知道。一个不知道技术细节的架构师，却完全可以做出清晰的架构，带领程序员最终交付软件。

 

@经理

在公司看技术书、看PPT/PDF是受鼓励的吗（我观察了下周围的同事，基本上班不是盯着eclipse就是几个网页，看书或者ppt、pdf的人很少，有时在公司看会儿，总觉得别人会觉得你很闲没事干，这个也许是我的幻觉。。）？在项目的间歇，除了解一些bug之外，是不是可以鼓励（尤其年轻同事，需要学习的地方太多）去多看看书、技术文档、做些技术任务什么的，因为白天的时间很宝贵（我不知道别人的生活习惯是什么样的，我是白天上班精力最充沛，脑子也最快，记忆力最好，晚上回家，吃完饭玩会休息会，也快9点了，坐下看书、写写代码或者看电影，即便看书脑子不如白天快，等到11点以后，脑子开始比较清醒了，却要快睡觉了，偶尔熬到晚上一两点，第二天发现效果并不好，且影响第二天工作，而且业余时间比较零散）。

 

我是心直口快的人，希望这些东西对个人和团队有用。有什么问题意见欢迎指正。

 

同事B针对这个项目的总结：

这是我经历smartsearch关于完成项目计划和控制质量的一些感想，请大家讨论指正。

 

1.关于项目沟通交流，应该多从他人角度出发多方位思考问题，从而避免个人先入为主的偏好，以迅速得到优化的结果。以拼音规则为例，我当时盲目坚持了一些规则，之后事实证明它们并不合理，从而影响了进度。

2.关于棘手问题的处理。不管是dev或者maint，项目成员不可避免会经常遇到难以处理的问题。所以需要一个较为格式化的方法？把这些存在于个体的不确定性变成风险可控的过程。

3.关于设计实现和编码：

   代码应该符合普遍认同的结构。类似事件处理的时机和放置位置，各类模块职责划分等。这点上个人困惑较多，应该多参考理解其他代码。这点归结为需要增强技术水平，这是终极的手段。

   在既定水平情况下，平衡需求价值和实现难度，选择最有效的方法来达到目的。（比如我们的dialpad和callbutton比较复杂但也没有很炫，带来不少难度和问题，或许可以选择较为简单的方案）。

   对于危险的场景，需要从始至终的警惕，并清晰的控制它们影响到的范围;如果不能确定或者有未预期的风险，应该设法避免。比如在查询出了一个cursor的时候，就要留意它经历的所有路径，一直到确保它安全关闭。比如设计UI和后台任务交互的情形，从一开始就要考虑它们的同步、频繁创建销毁UI和后台任务之间的影响。有不少的crash在于初期实现不完备代码后，后续开发忽视遗忘了其中的风险。

4.尽早满规格的测试（当然需要设定一个规格）

   这样避免demo时期的东西被带到发布版本。有一个batch sql查询的crash，以及性能问题，如果测试大规格数据是可以尽早发现的（这个测试较简单并不会带来附加的工作量）。

5.对于已知问题或者迹象，需要尽早主动根治，防止扩大扩散。

   有一个多次横屏crash的问题，在xq的坚持下在fix后才得以发布。可以想象如果勉强发布会带来更多的crash DMS和工作量。

   有不少crash DMS是在日常测试中偶尔出现过的，但是没有放到足够的级别。

   如dialpad光标问题经过了多次修改，但都是临时修补，导致问题反复。

 

同事A的总结：

1.项目范围的控制。

        项目的范围应尽早确定下来并且尽量少变化和不变化。对于新的需求要考虑对现有功能和项目进度的影响来考虑是否接受。

        在smart search的开发中，对UXC的一些新需求缺少通盘的考虑并加以控制，占用了不少的时间而影响了项目的进度。

2. 软件架构。

        虽然以前写过一些code，但是从架构的高度来考虑软件比较少。smart search中的一些架构设计缺少相应的调研和评估，这个方面需要不断的学习。

3.时间的管理。

        在功能开发的过程中，浪费了不少时间在一些不重要的事情上。并且对一些功能的开发考虑的过于理想，影响了其他的开发进度。

4. 进度的管理。

        对于功能开发的整体进度没有很好的把握，虽然Jason在管理和跟踪进度，但是整个的开发还是处于一种很忙碌的状态。

5. 技术细节。

      对于android的了解还比较肤浅。需要先对android进行全面的了解，然后对可能会用到的技术细节进行深入的学习和研究。

 

虽然在smart search开发的过程中，暴露出了很多问题，但是我认为我们也有很多方面做得很好，需要继续保持。

1.和其他team的交流和沟通。和我们打过交道的team，好像没有人说我们team很难沟通，不过也可能是我没有听到。J

2.解决问题的能力。Smart search开发到现在，遇到了很多大大小小的问题，我们都快速的解决掉了。

3.工作态度。Smart search的开发遇到了很多困难，但是我们没有逃避，而是积极的承担和解决困难。

4. 学习能力。对于不了解的知识，我们能够很快的学习和掌握，并加以利用。开发完成后，能够总结和反思开发中遇到的问题。