代码评审

 三个月来经历的事情颇多，入职，培训，参加项目组，现在马上面临着转正答辩了。不能说已经完全从一个学校任转变为一个企业人，但心里已经开始在反思如何做得更好，相比刚到项目组时，心里的波动，签约时的犹豫，现在的心里算是平静了许多，因为改定的事都尘埃落定了。有些事不是我能力所能及，能做的只是在岗位上做得出色。一个老员工说刚来时大家都这样，过了几年就会习惯了，我说也就是麻木了，我不想麻木，在任何时候！导师和我说只有被蹂躏，才能茁壮成长----我相信这句话，呵呵！
以后我会尝试把在公司的一些感想写下来，主要项目管理方面的，因为大家都说，来HW就要学习她的管理，平时多想想管理方面的事总不会有坏处吧！

现在的项目是未来公司几年这方面产品的支柱，所以投入的资源比较多。刚进项目组时正好是SRS评审阶段，也算是参与了大部分吧，运气比较好。现在是编码阶段，预计将持续两个多星期。先说编码前期关于代码评估的一个问题。
代码量评估事非常重要的，这关系到PDT对项目组的人力计划和阶段持续时间，评估过高，PL就不合格，项目组的就会被扣分；过低则更惨，因为这意味着你的组员们会拼命来赶进度。我们项目组因为以前都是编写WM，对C的评估就出现了偏差。那我负责的某个模块来说，开始认为有2000行，实际编完后核心代码才不过500行。所以我就被PL加了好几个任务，不得不看其他相关文档。前面的时间被浪费了，而后起有的赶，非常影响进度。
因为估计的问题，PL还被TDT逼着要求压缩开发进度，幸好PM顶着才算作罢，那天PL是相当的郁闷。

代码评审一般应该在编码结束后作，但是考虑个人的进度不一样，到时候集中到一起可能时间太紧，PL决定只要自己愿意就可以先拿出一部分代码评审，这样还可以提醒自己以后注意一些必要的地方。我不知道这样符不符合公司的规范，不过这样处理还是很有道理的。因为根据公司以往的经验，代码的走读能发现相当比例的问题，所以项目组比较重视，今天进行了第一次评审。
但今天的代码评审相当的低效，下午1000左右的代码花了2个小时，晚上的1000行也花了2.5个小时。还把大家一起叫过去评审，好多人根本没发表意见。我们新员工开始几次去看看还可以，后面的就没有必要了，老员工则没必要参加不相关模块的评审，除非他自己有兴趣，否则不应该强制要求。评审时关注点集中在异常处理，接口同步等方面。其中异常处理花了最多时间，考虑的点非常细，好多我觉得根本没必要（不过可能使自己经验不够吧，多注意异常情况总没有坏处）。