苏的笔记的博客网

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://jimsu.yourblog.org/logs/633273.html

新版本的开发进行得如火如荼，整个版本的周期预计10个月，有11个左右的研发人员参与开发，到目前为止应该说已经可以看到产品的轮廓了。在整个开发过程中，团队不断磨合，不断摸索，对需求管理、开发流程等不断改进，虽然还存在不少问题，但大家对一些基本准则基本认同。在这个阶段，我们着重强调了code review、单元测试、反思改进。 对于code review，以前也进行过，但没有形成系统，时断时续，成为开发中的鸡肋。这次使用过程中，有不少体会。 1，必须有编码规范，版本管理规范，这些convention需要在大家认可的基础上不断完善。“不以规矩，无以成方圆”，有了规矩，就需要强力执行。 2，尽量用自动化工具，定期生成报告，减轻大家工作量，提高生产率。我们使用的是eclipse集成开发环境，里面有很多实用的插件，subversion、checkstyle、jupiter、ant、cruise control都是一些很好用的工具，当然，工具需要按照团队的实际去设置哪些该屏蔽掉，这个过程需要有互动、不断调整的过程。比如说checkstyle缺省的规则会报无数warning，严重打击大家的积极性。 3，code review中对提出的一些有代表性的问题，需要提出并加入到编码规范中。 4，对于code review的时间安排，个人觉得不宜太频繁，最好能固定下来review的周期。我们最早是每周一天，每次2人讲解代码、设计思路，然后大家各自在下周花半天去code review，并统一在下周的一天进行这些意见的总结并安排下一轮的讲解，这样花费的时间太长，大家抱怨真正开发的时间太少，没办法完成自己的任务，后来马上调整，每2周进行一次，每次只安排半天进行讲解和review总结，这样就需要在总结前把所有问题在总结会前都分类、统计出来，及时公布在wiki上，节省大家的时间。总结会后需要有人对这些问题进行跟踪，避免只提问题，不修复问题。 5，要有制度保证每人都去认真的做了review。Review不是为了让大家完成一项任务，而是为了让团队相互间理解代码、改进代码和设计，同时取长补短。如果没有养成一个习惯，刚开始实行起来是很难得，大家会有不少抱怨，有的人提得少，有的人干脆不提，有的人胡乱提，这都会挫伤提得多的人的积极性，需要及时提出。 单元测试能有效提高生产率和产品质量，它是一种白盒测试，一般有开发人员自己进行，可以说是产品测试的第一道关卡，如果没有良好的单元测试，质量是无法保证的，即使被测试人员发现了，后期也只能做一些fix bug的工作。真所谓软件不是改出来的，而是做出来的。 单元测试的内容其实很难界定，一般来说可以有功能测试、性能测试。对于功能测试，在用例上又可以细分很多粒度，一般在java应用里面都使用junit。本次开发过程中，我们强调需要对重要的类必须编写测试用例，而且有专人去检查用例，使用ant定期生成报告。听起来是件令人兴奋的事，但执行起来问题很多。首先大家对单元测试认识不够，对哪些类需要测试、哪些类具备可测试性存在分歧；同时有人抱怨编写太多的测试代码花费了太多精力；而且有些代码重构后，测试代码并没有同步；ant生成的报告，有时大家并没有理睬。虽然事先做了很多准备和约定，并不断改进，但单元测试真正成为武器还有相当一段路要走。 开发了几个月，有得有失，所以需要选择合适的时机刹车进行反思改进，倾听团队的声音，对代码的问题、工作安排、流程上的问题、设计的建议都需要集思广益。避免开快车最后团队士气不高，产品进度和质量失控。 产品还在开发中，我们还在……