我觉得 Code Review,变量名,编码风格等这几个相对于其他还是稍微次优先级的,尤其关系到公司规模和发展情况。

我觉得做到以下两点基本就可以了,不管什么样的公司,

第一,运行正确结果,这样就意味着没有足够的单元测试是不行的(人类思维本身就不善于把理解立体地翻译到逻辑),在做好测试的时候,基本可以把初级程序员的大部分缺点都消灭了,当然很多人没有做到。

第二,别人要你给解释任何层次的业务对应到代码的时候,十几秒到几分钟内就应该找到,这个水平是非常有难度的,只有资深程序员和架构师可以勉强做到,其中要求你的代码得是设计合理,勤于优化结构,而且没有抽象过程和部分函数式编程的能力是做不到的。

通常说的 Code Review ,其出发点主要是为了解决协作的问题,包括编码风格,这个对水平低的人是有好处的,对水平高的人是有损伤的,包括阻碍了思考以及时间成本。所以个人建议换一种方式, Code Review 前做好测试,然后给别人讲思路,确保这代码三月后适当水平的人都能维护,那基本就OK了。

说个奖励的问题,好像是应该给代码写的好的人更多奖励的,可是公司是靠业务盈利的,所以看不到直接贡献,还是倾向于奖励对业务贡献更多的工程师,那这个就只能看部门了。如果公司有相当的奖励或尊重,那么团队代码文化就会好多了。

总结一句,幸福的家庭都是相似的,不幸的家庭各有各的不幸。


20150622 补充:

以上想法是一段时间前最初回复在公司的技术微信群里,在地铁上用 iPhone 仓促写的。如今我也并不想改,只是做了下分段,还是保存当初原滋原味的思绪比较好。

原本想法是, 用 Code Review 来提高团队代码质量是个伪命题,很不容易执行,也很少听说有公司执行(除了某些财大气粗的 Google 等大公司,或者有时候装装逼的坚持某些奇怪的软件原则的人),因为太难了,我认为比加单元测试都更加划不来。

以后我会专门写文章从原理层面详细解释。