|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-02
kidneyball 写道 jinnianshilongnian 写道 kidneyball 写道 jinnianshilongnian 写道 kidneyball 写道 谈谈我们公司现在采用的办法（20人左右的开放团队）：
1. 首次提交单元测试分支覆盖率（Branch Coverage）要达到80%以上（采用Maven的Cobertura插件来保证）。在后续的开发中，如果单元测试的分支覆盖率有所提高，则把数值调为实际值，只准增加不准减少。Team Leader定期检查pom.xml中的设置是否被队员意外调低。 有些人可能觉得这种方式太迂腐。不过它最大的好处是能有效地引导程序员把包含复杂分支结构的程序段抽成独立的方法。原因是，象楼主写的那种复杂条件判断，为了达到完全分支覆盖，你要分别写 子判断*2 个测试用例。如果这种条件式嵌在一个100行的方法里，你就需要为这N*2个测试用例准备上下文环境。只要不算太笨的程序员，很快就会发现最省事的办法是把这个复杂判断式抽出来作为一个独立的短方法。而对于管理者来说，这种方式很容易操作，不用苦口婆心地劝程序员们不要写长方法了。一段时间之后，程序员们就会自动养成倾向于写短方法的习惯。 当然为了达到85%以上的分支覆盖，必须把编写单元测试的时间也算到进度里。现在我们并不对单元测试的代码质量作很高的要求，编写单元测试的时间大概是写相应功能代码时间的四分之一到三分之一。 2. 鼓励程序员之间非正式的交叉代码审查。鼓励程序员在维护代码时，如果发现有可疑或者不明白的地方，通过看历史记录和Blame信息，找到可疑代码的原作者私底下咨询。 3. 鼓励使用Git作为本地代码库（公司的主代码库使用svn，通过Git-svn与本地库整合）。这个规则主要是为了避免一次性提交大量代码，保证保持详细的历史记录和Blame信息（Blame信息加上正确的命名规则可以取代大量不必要的代码内注释）。而且Git的Bisect功能也是排错的一把利器。 谢谢建议。 我想再问个问题，比如需求不明确或业务经常变，单元测试进行测试粒度适合吗？还是大部分是集成测试？ 有没有考虑使用BDD开发？ 能否问下你们是否进行自动化的单元测试/集成测试。 我们不是TDD，而是先写功能代码再补上测试用例的传统做法。只要你能保证拿到30%的额外时间（例如本来要三天完成一个小目标，现在要四天，其中一天用来写前三天所开发内容的单元测试），那么需求变化和粒度都是伪命题。不管需求怎么变，单元测试反正就是把你的进度拖慢30%左右（如果框架完善的话可能会更少），至于粒度，单元测试能达到的最大粒度就是分别100%行覆盖和分支覆盖，其实工作量也不会大很多，但实践上有总会有一些代码不宜测试（例如调用了框架的静态方法），一定要覆盖这些代码显得有些得不偿失。我个人觉得达到85%的行覆盖和分支覆盖就可以了，主要是迫使程序员写出便于测试的代码。 集成测试我们有专门的QA，据我所知他们也不用什么自动化工具（跨浏览器支持也不容易自动测），就是人手测试，主要技能是文档和沟通。这样的话回归测试比较麻烦，所以我们要求发版（大概一个半月到两个月发一次版）前两个星期建分支，停止向发版分支上提交新功能，发版前一个星期停止修改重大bug（作为known issue留到下一版本修正）。 单元测试肯定是自动化的，整合到maven build里每次构建都跑一遍。 嗯，比如有个紧急任务需要下午上线，是后来再补上单元测试？还是有些直接不写？ 你们是做产品？ 单元测试肯定是自动化的，整合到maven build里每次构建都跑一遍 ： 每次跑是不是太慢了，你们为嘛不使用持续集成服务器呢？ 我们一起通过teamcity来做自动化测试，如果测试失败，发邮件通知 是做产品。既然紧急下午上线，肯定是先不写，修改pom.xml先exclude改动的class（但不能调低覆盖率限制，便于审查），后面再补上。一般没做单元测试的程序员自己开一条JIRA来记录需要补上的单元测试，然后把JIRA号写在pom.xml的提交comment里。Leader同步代码时发现pom.xml被改动但Comment里没有JIRA号，就会要求这个程序员自己补上。 单元测试运行速度目前还好，我们这边开发机的标配是intel i7+8G RAM+固态C盘，本地用git，一般都把代码clone到内存虚拟盘里build，全构建一次大概1分多钟（其实直接在C盘构建也差不多）。而且一般就是同步代码后build一次，其余时间都是增量构建，不用跑test了。开发环境的服务器（包括SVN）归基础架构部门管，我们开发这边一般就不理了，有啥就用啥…… 恩，你们的机器好好啊（intel i7+8G RAM+固态C盘），  。
全构建一次大概1分多钟（测试就20秒左右吧，这个本地跑很快） |
| 返回顶楼 | |
|
发表时间：2012-04-03
说句题外话，refactor了以后确实程序比以前容易读了，但是还可以继续refactor。比如第二个if，如果是一个新雇的程序员来了不一定能看懂第二个if要干什么。第三个if有一个code smell那就是一行中最好不要出现多于一个“.", saleOrder.getOrder().getState() 有两个”." ， 这个有可能可以refactor成一个function 叫 “boolean isOrderStateWaitPay(OrderStateEnum orderState)"
|
| 返回顶楼 | |
|
发表时间：2012-04-03
楼主问了 ”如何保证所有队员都能按照一致的约定编程？如使用checkstyle等工具自动化的检查。”
我觉得让整个团队的人都有一致的约定最便宜和有效的方法是pair programming和code review。我看过一个blog写一个国外的公司在国内雇了20多个outsource，这个公司派去中国20个人在接下来的两个星期里面和国内的20个人不停的pair programming，每两个小时换一个pair的人。具此blog讲，国内的20个人在两个星期内完全理解了他们的设计理念，效果很好。 楼主还说 “不是每个人都是优秀的程序员，因此需要制度等手段来强制程序员按照比较正确的路走” 这个我不太同意，我觉得如果你要建立一个顶尖的公司，每个人都必须是优秀的程序员，当然不一定每个人一开始都是，但是在几个月半年以后他们必须是。 |
| 返回顶楼 | |
|
发表时间：2012-04-03
chaooo 写道 楼主问了 ”如何保证所有队员都能按照一致的约定编程？如使用checkstyle等工具自动化的检查。”
我觉得让整个团队的人都有一致的约定最便宜和有效的方法是pair programming和code review。我看过一个blog写一个国外的公司在国内雇了20多个outsource，这个公司派去中国20个人在接下来的两个星期里面和国内的20个人不停的pair programming，每两个小时换一个pair的人。具此blog讲，国内的20个人在两个星期内完全理解了他们的设计理念，效果很好。 楼主还说 “不是每个人都是优秀的程序员，因此需要制度等手段来强制程序员按照比较正确的路走” 这个我不太同意，我觉得如果你要建立一个顶尖的公司，每个人都必须是优秀的程序员，当然不一定每个人一开始都是，但是在几个月半年以后他们必须是。 人人都想成为优秀的程序员吗？ 未见的吧，我见过许多程序员就是以这个行业谋生，不想学习，只想玩，只想赚钱！从不想如何规划自己成为更好的程序员。所以国内行情就是这样。 我们是我们，既然来了iteye论坛参与讨论 大部分人都想成为好的 优秀的 甚至卓越的！ 但我们也要换位思考下，很多人真的不是这么想的！ 很想体验结对编程！  有机会一定试试！
|
| 返回顶楼 | |
|
发表时间：2012-04-03
jinnianshilongnian 写道 人人都想成为优秀的程序员吗？ 未见的吧，我见过许多程序员就是以这个行业谋生，不想学习，只想玩，只想赚钱！从不想如何规划自己成为更好的程序员。所以国内行情就是这样。 我们是我们，既然来了iteye论坛参与讨论 大部分人都想成为好的 优秀的 甚至卓越的！ 但我们也要换位思考下，很多人真的不是这么想的！ 很想体验结对编程！ 有机会一定试试！呵呵，是的，这个我其实也深有体会，80％的人都是得过且过，当一天和尚撞一天钟。想要改变这个是很恐怖的（我试过），尤其是如果一个公司大部分都是这样的话。 结对编程我觉得最好玩的是第一个人写单元测试，另一个人写代码来通过那个单元测试，5分钟一换，挺逗的。 |
| 返回顶楼 | |
|
发表时间：2012-04-03
chaooo 写道 jinnianshilongnian 写道 人人都想成为优秀的程序员吗？ 未见的吧，我见过许多程序员就是以这个行业谋生，不想学习，只想玩，只想赚钱！从不想如何规划自己成为更好的程序员。所以国内行情就是这样。 我们是我们，既然来了iteye论坛参与讨论 大部分人都想成为好的 优秀的 甚至卓越的！ 但我们也要换位思考下，很多人真的不是这么想的！ 很想体验结对编程！ 有机会一定试试！呵呵，是的，这个我其实也深有体会，80％的人都是得过且过，当一天和尚撞一天钟。想要改变这个是很恐怖的（我试过），尤其是如果一个公司大部分都是这样的话。 结对编程我觉得最好玩的是第一个人写单元测试，另一个人写代码来通过那个单元测试，5分钟一换，挺逗的。 很多人上班其实把很少的时间花在写代码上，大部分时间花在网络上。结对编程你说很有意思，而且具有监督作用，可以尝试下能否更有效的让员工工作。 |
| 返回顶楼 | |
|
发表时间：2012-04-18
浏览了这么多回复，学习了更多
|
| 返回顶楼 | |
