说说Code Review

做code review，同一块代码最好同一个人做，这样可以根据svn的更新做，比较快速。
当然，做代码规范的最好了解业务，不但可以找到代码问题，也可找到业务逻辑问题。
还有是可以对核心代码做code review

一定层次的Code Review是很有必要的，但是不能过于苛刻，像以前的项目组老大原先是做.Net的，居然为了一个方法开始的大括号是跟在方法名后面还是一下行开始跟我纠结很久。还有变量取名，String sql = xxxx，他硬是要改成String sSql = xxxx

“比如和这位牛人沟通过程中，发现他对代码性能非常敏感”
这种拿着锤子看什么都是钉子的，怎么能算牛人。

你应该理解我指的牛：算法功底。

水瓶座的我不知道，但是处女座的，我却深有同感

我觉得星座的说法完全扯淡，虽然我信星座。水瓶座的人注重设计，代码一般很好的；处女座的人神经兮兮，想法诡异，别人都认为是规范，他非要玩个性化，代码反而很不能让人接受。当然我这也是扯淡。这之间的关系，不是你说的那么简单。

最近在做code review的工作。两万多行的改动，涉及大小功能点也有十几个。

我们的pm，找了5个人去review，其中2个架构、3个高程，reivew期是十天。最近这项工作也接近尾声，我作为开发方面的负责人，我的感觉是，有点浪费。虽然，可以review出一些问题，但都不是那种伤筋动骨的，例如修改格式、copyright、变量名、删减多余空格等等，但这些事情，我们开发这边两个人，前后改了好几天，其中为此还加班三次。可能对于一个不用考虑生存问题的公司来讲，他们看重流程和规范，但是从我之前经历的中小公司来看，这种力度的review，代价太大，承担不起。
另外，代码管理工具应该也足够的好，例如我们现在用gerrit去管理代码。
code reivew在我感觉应该是一次补漏行为，它本身就有局限性：如果严重的问题在这个时候才暴露出来，那是不是应该反思前面的阶段。

Code Review的出发点是应该在团队内部高度统一的，这样才能在实施过程中不至于流于形式，才能纠正技术、业务问题，才能在Code Review中提升团队成员的编程风格

其实我觉得Code Review的最终产出，也是最有效的产出应该是团队成员的成长

很多时候，项目是否在后期陷入泥潭。取决于前期对于细节问题的考虑深度。

我个人不太建议在写代码的过程中，过分的强调注释的覆盖度。很多时候，代码不是一次就调通的，甚至一些时候，在代码完成后，要对实现方式进行修改。这个时候，有多少人会在修改代码的过程中，修改注释呢？那么有时候我们看到的代码，可能是1.5版本，而注释是1.0版本，这个时候，注释没有起到帮助的作用，甚至有时候会成为误导。

code review。有时候或许可以把对文档整理，文档修撰结合起来。

当然最终还是要说：对于新入行的人员，不论如何强调代码的规范性，都不过分。最少在开始的短时间内，要养成他们的习惯。

我有一个习惯，在写完代码后大约几周，因为需要改进，再去review原来的代码，发现那些代码比较丑陋，于是重构啊重构...

我曾经用Flex开发过业务框架，然后基于该框架开发业务系统。因为开始对flex的不太了解(没有看到过任何公开的项目)，所以花了一个月时间大重构，然后项目其它人也跟着重构。
一个新项目，代码不写上上万行，很难发现之前的代码重用性、健壮性等有问题。

基于我的这些经历，我觉得如果一个人对自己的代码smell要求高，那么他会千方百计去改进，即使自己加班。
当然，这很不普遍，所以没有通用性，我们也不应该在项目管理中有这样的假设。但是，作为一个PM，一定要让他的团队(辅导和激励)，喜欢上自己的代码。如果一个人觉得自己和别人的代码都很恶心，是不可能改进代码质量的，即使改进，也是应付。而这，往往是Code Improve的前提。