|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
时间：2008-06-27
code review 到底review的是什么?
命名格式? 重构? fxcop规则? 每个人的看法都不一样. 我的code review意见:保持架构一致性,即BLL和DAL的代码一定要符合架构,还有关于技术尽量simple, 不care你具体用了多少循环或者调用多少方法,只要没有用到一些很特殊的hack式操作,一般都没有问题.对于独立模块,你自己用了相对成熟的技术框架,例如nhibernate,那也是没有问题的,但是你需要提供一份nhibernate技术指导手册及维护计划,保证这部分内容不会由于你不在而没有别人能够维护. code的可维护性是review的一个重点. |
| 返回顶楼 | |
|
时间：2008-06-27
yamakasy 写道 code review不是必须的，但是非常推荐。一个非常简单的理由，你敢把你的代码拿来让别人分析，挑毛病吗？你的代码和设计书真的一点问题也没有，我不相信，你如何保证你干的活的质量，一个人全权负责？如果可以，说明你的客户只需要这样的质量。比如以前做过的金融的项目，有问题的时候，会有罚款，你说你如何保证质量，review，不单是代码，全部让别人review，能在相当的程度上避免很多问题，但是不是所有。
有一个问题要搞清楚，必须要做的事情，可选的事情。可选不可选不是由具体的干活的人决定的，是由项目负责的人决定的。如果由于时间紧，比较困难，是如何做的问题，什么形式做，什么时候作，谁来做的问题，时间紧不是不做的理由，做不做负责人判断。具体写代码的人没有权利选择，但是如果你被赋权了。 code review本身并不无聊，从这个可以透视出很多的问题。尤其是质量问题。 test用来干什么? 我的看法: code review 提供可维护的检查 unit test 提供程序员调用的保证 integrated test 提供项目质量的保证 |
| 返回顶楼 | |
|
时间：2008-06-28
什么pair/review这些方法都不好,好的办法要从中国传统智慧中去寻找.
南北朝时北朝有个皇帝赫连勃勃,要建首都(统万城)的城墙.为了最大程度保证质量,他把团队分为两组,一组施工,一组质监.施工组建完一段墙后,质监组过来做检查,检查办法是用铁枪使劲往城墙上戳,那么结果无非两个,一是把墙戳个坑,或者是墙毫发无损. 对于第一种情况,皇帝的措施是这样的:把施工组的人全部砍头.第二种情况的处理大家可能猜到了,就是把质监组的人杀掉. 采取这种措施的成效非常喜人:近2000年过去了,这个统万城依然屹立不倒. 诸位认为这个质保措施用于软件业,会有什么效果? |
| 返回顶楼 | |
|
时间：2008-06-28
楼上，如果放在软件业，效果很明显，就是没有人呆在执行这个残忍措施的公司。不能乱套经验。
其实要不要review，采取何种方式review，是和楼主的项目特点、团队具体情况密切相关的，看看有谁有成功的review经验，并且项目、团队也和楼主类似。 |
| 返回顶楼 | |
|
时间：2008-06-30
xuby 写道 什么pair/review这些方法都不好,好的办法要从中国传统智慧中去寻找.
南北朝时北朝有个皇帝赫连勃勃,要建首都(统万城)的城墙.为了最大程度保证质量,他把团队分为两组,一组施工,一组质监.施工组建完一段墙后,质监组过来做检查,检查办法是用铁枪使劲往城墙上戳,那么结果无非两个,一是把墙戳个坑,或者是墙毫发无损. 对于第一种情况,皇帝的措施是这样的:把施工组的人全部砍头.第二种情况的处理大家可能猜到了,就是把质监组的人杀掉. 采取这种措施的成效非常喜人:近2000年过去了,这个统万城依然屹立不倒. 诸位认为这个质保措施用于软件业,会有什么效果? 提问:修墙的人死的多还是质检的人死的多? 
|
| 返回顶楼 | |
|
时间：2008-06-30
史书上没讲。
我猜想的结果是最终没有人能活下来。 |
| 返回顶楼 | |
|
时间：2008-06-30
xuby 写道 什么pair/review这些方法都不好,好的办法要从中国传统智慧中去寻找.
南北朝时北朝有个皇帝赫连勃勃,要建首都(统万城)的城墙.为了最大程度保证质量,他把团队分为两组,一组施工,一组质监.施工组建完一段墙后,质监组过来做检查,检查办法是用铁枪使劲往城墙上戳,那么结果无非两个,一是把墙戳个坑,或者是墙毫发无损. 对于第一种情况,皇帝的措施是这样的:把施工组的人全部砍头.第二种情况的处理大家可能猜到了,就是把质监组的人杀掉. 采取这种措施的成效非常喜人:近2000年过去了,这个统万城依然屹立不倒. 诸位认为这个质保措施用于软件业,会有什么效果? 这个质监组是做code review还是做 test呢? |
| 返回顶楼 | |
|
时间：2008-07-01
毫无疑问是 test.
质检组的人不会管你砖砌的是不是很"面向对象",也不会管你用了一个"资源"(比如一个铁锹)之后有没有"释放". 而且他基本上是黑盒测试,只管拿条大枪往墙上戳. |
| 返回顶楼 | |
|
时间：2008-07-04
photon 写道 其实要不要review，采取何种方式review，是和楼主的项目特点、团队具体情况密切相关的，看看有谁有成功的review经验，并且项目、团队也和楼主类似。 我觉得这位朋友思考的方向挺对，其实就像软件没有银弹一样，也没有一种review方案能满足所有的情况 所以，我们公司technical committee最后达成了一个统一的意见：我们定义出几种可选的方案，由特定项目的项目经理或资深人员在项目开始时选择一个适合自己项目的方案。 为什么这样做呢？ 1。 没有一种方案可以适合所有的项目。 2。 开发人员是一个充满个性和激情的团体，review工作是一个充满主观能动性的工作，如果不是他们认可的方案或做事方式，注定了工作的效果不会太好。 3。 人和人的观念是软件项目的一切，规矩只是辅助工具。 |
| 返回顶楼 | |
|
时间：2008-07-04
让质检组的人来code review,与他们的测试有何区别?
还叫什么code review? xuby 写道 毫无疑问是 test.
质检组的人不会管你砖砌的是不是很"面向对象",也不会管你用了一个"资源"(比如一个铁锹)之后有没有"释放". 而且他基本上是黑盒测试,只管拿条大枪往墙上戳. |
| 返回顶楼 | |
