关于软件生命周期模型和Code Review的讨论。请大家发表意见。

这是我在CSDN上对于这两个问题发表的看法的帖子，但是自己不是很满意，特别是Code Review。希望大家发表意见。
http://expert.csdn.net/Expert/topic/2597/2597477.xml?temp=.5242426
http://expert.csdn.net/Expert/topic/2600/2600563.xml?temp=.2398188

这个 baser 显然是没有写过多少代码，就是我前几天画出的“言必称 CMM”的一类人。copy & paste 是阿猫阿狗都会做的事情。瀑布模型的罪恶 Brooks 早已在《人月神话》中列举过了。连 RUP 都认为软件应该采用迭代模型来开发，这个 baser 显然还生活在 1980 年代。

我完全赞同 ozzzzzz 兄的看法。以前与 xidao 兄交流时他说：“即使你有杰出的人，如果他出工不出力，你仍然是没有办法。”
如何让员工出工又出力，你就得有些智慧了。总之一句话“攻心为上、攻城为下”。不收买人心能行吗？学学刘备摔孩子吧。刘备再不济也比你聪明。

CSDN 可有一帮“砍爷”呢，跟他们搅在一起，能把问题讨论清楚吗？呵呵。

关于软件生命周期模型我完全同意 ozzzzzz 兄的看法（没必要为了表示我比 ozzzzzz 兄更高一点点而提出一些不同意见了），我确实完全看过这个帖子，而且认为 ozzzzzz 兄的意见逻辑上是严密的。
ozzzzzz 所说的基本上也是我多年开发得到的经验，不过 ozzzzzz 兄总结得更加系统和细致。

嘿嘿，毕竟比你活的念头长久啊。其实我更关心是关于Code Review的那个帖子。我实在是被这个东西引起的纠纷给搞怕了，所以才搞了一个不Code Review的Code Review方法出来。
关于CSDN的侃爷现在我是老大，那些天天玩理论的家伙玩理论也玩不过我，玩实践也玩不过我。我早就把他们赶跑了。不过时不时有些刚毕业和没有毕业的学生，发表点无知的言论也是可以理解的。毕竟谁也不是生下来就是毛泽东。

ozzzzzz的文章果然让我开阔了思路。我这些天也在想代码复查如何实施的问题。先前我找了一堆编码规范的文档，每篇都有几十页那么长，我想，人家提的规范，字字句句都挺有道理，要是全收进来，收的时候累一次也就算了，可是哪有那么多资源天天比着厚厚的编码规范检查这么多人的代码啊？ozzzzzz提到了一些对策：
1、结对编程
2、检查单元测试
3、利用代码风格工具
我认为这些应该都是比较有效的方式，不过还是有一个问题要请教：经理希望通过代码复查形成工作质量考核表，那么应该依据那些指标来做呢？
昨天听余世维的管理讲座，其中正好有一点和代码复查的问题有关系，讲到团队的自主性时，他提到了QCC这个词，QCC=QualityControlCircle，叫Circle的道理就是QC应该是由团队自发的去做的，相互的检查，而不是由专门的QC部门去搞，自发的QC效果会好的多。这一点和结对编程的思想很像。我看真是英雄所见略同啊！
那是不是可以这么说，被动的复查再怎么样也不如自发的相互检查效果好，与其建立QC部门、制订QC工作流程，不如说服程序员养成QCC的习惯，或者干脆结对编程？

一个建议，不要根据 Code Review 的结果进行业绩考核，以至于决定员工的待遇。这样开发人员会更积极地进行 Code Review。
Code Review 只需要制订出来一些客观的标准就可以了。结果出来后如果工作做得不好，员工面上无光，自然会自己想办法去改进。PM 再做批评、甚至惩罚是多此一举。
没有人会不犯错误，要允许员工适当地犯一些错误。“水至清则无鱼，人至察则无友”，PM 要学会在一些场合睁一只眼闭一只眼。

dlee说的有理!

在我看来Code Review不是质量检查部门的工作，而是开发团队内部自己的工作。质检部门应该是独立于开发团队之外的第三方，他们负责的是检查程序是不是按照客户的需求运行，是不是没有考虑到一些特殊情况。比如是不是不能处理姓名中的空格，是不是不能处理5个字的名字，是不是不能修改人的性别这些功能缺陷；还有就是检查是不是一些一些数据在面向时候的无效会让系统崩溃，系统的容错性能如何，系统的操作性如何，系统的外观，系统的性能。这些都是黑盒测试的东西，是不适合开发团队自己作的事情。所以最后的把关还是需要这样一个部门来作的。
关于绩效评估的问题我考虑了差不多已经5年了，答案还没有。但是我已经知道一些东西肯定不能用来评估绩效。Code Review就是其中最不应该用来作处罚的一个手段。你可以通过Code Review对于发现问题的人提出奖励，但是绝对不能因此就使某些人受到贬低。而且发现问题的人不是解决问题的人，最终问题还是要依靠写那些代码的人自己去解决。而在团队中有些人善于解决问题，有些人善于发现问题。可是谁也不愿意别人指出自己什么什么地方错了，于是就经常为此产生争吵。而我提出以检查单元测试代替检查代码，就是想避免这些争吵。如果你在这个本来就不平静的锅里，在放进绩效评估这碗热油，那你就要小心了。
关于绩效评估我一有突破，自然会告诉大家。现在我们还不是讨论如何解决这个问题的时候，我只能告诉大家你不能怎么作，我不能告诉大家你应该怎么作。

同意ozzzzzz的看法。
我想单元测试的检查可以以测试用例为基准，这样只要测试用例没有大的问题，单元测试的检查也会轻松的多。另外，使用代码辅助工具可以解决一部分问题，但是仍会有相当一部分问题还必须通过人工检查才看的出来。

我不太提倡大家互相看源码挑毛病的正式做法，这样往往引起矛盾。而我在看来项目组的团结是第一位的，即使有的时候项目会失败，我也宁愿承担这个代价。因为不团结的团队我认为能成功完成一个项目。所以我喜欢使用单元测试这些间接的手法去发现问题。但是这只是发现了问题，问题具体在什么地方，是怎么发生的问题，还是需要代码的作者来解决。当然作者可以寻求别人的帮助，可是主动的这样作和被动的这样作对于作者的心理影响显然是不同的。

我也提倡　Code Review,而且我个人绝对不是为了发现问题而进行的，它同样是一个提高的方式（思想，技巧，等等很多方面）