Comments on: 我们所不知道的Code Review

By: Stephen. H. Wang

Stephen. H. Wang — Fri, 13 Nov 2009 04:16:43 +0000

合理的应该是诸如Unit Test Coverage 100%之类的目标。
这个指标达到了，一定程度上说明了质量的状况。
但是发现多少Bug根本就是扯淡，高手做的程序Bug很少，新手满篇都是Bug，凭什么定义一个统一的指标？

有的公司也挺有意思，定义了一个多少年工作经验的人的指标是多少。这就跟说多大岁数才能升到什么位置一样可笑。

By: DenMark

DenMark — Wed, 21 Oct 2009 13:42:25 +0000

举例来说，他们会定义一个比较莫名其妙的目标：千行代码Bug数，CodeReview必须发现多少，Unit Test发现多少，Integration Test发现多少。而且必须是一定的范围，理由是：发现太少是因为Review不充分，发现太多是因为编码不合理。

看到这段我真是又想说好,又想说我cao,又想哭.

By: Stephen. H. Wang

Stephen. H. Wang — Wed, 30 Sep 2009 13:16:26 +0000

盈利的好办法就是保留Bad Smell。因为这样用户用一段时间不爽了，就要求变更需求。这个时候，就可以开始估计新的工作量，而工作量当中包含了很多前一次开发就可以防止的事情….返工还要跟客户收钱。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
agile很适应产品开发，因为节省成本，易于变更是为自己服务的。
而定制项目更适应与CMM开发，因为各种报价依据充分，有说服力。看起来很规范。
Agile或者Refactoring,Design Pattern等技术方法更适于对已有项目的改造，告诉客户我们的比以前的好。
<<<<<<<<<<<<<<<<<<<<<<<<<<<

By: Stephen. H. Wang

Stephen. H. Wang — Wed, 30 Sep 2009 13:03:07 +0000

我想我应该写一篇文章：SQA does nothing in software developing procedure.

By: Stephen. H. Wang

Stephen. H. Wang — Wed, 30 Sep 2009 13:01:31 +0000

dreamhead>>

Bad smell没有人管，不是因为大牛不看，而是所谓的大牛们根本看不出来。

大牛们需要按照过程定义一步一步的执行。至于每一个过程什么是正确的，什么是优秀的，根本就没有定义。而只是定义了过程需要什么工作。

举例来说，他们会定义一个比较莫名其妙的目标：千行代码Bug数，CodeReview必须发现多少，Unit Test发现多少，Integration Test发现多少。而且必须是一定的范围，理由是：发现太少是因为Review不充分，发现太多是因为编码不合理。最后，导致交货以后，被客户发现的不合格率很高。另外，对于测试覆盖率的要求居然不是路径覆盖率和条件覆盖率等，要求的是，每千行多少个测试点。

所谓过程的公司更多的是关心过程的执行有无，而不是过程执行的合理性。

By: Michael Chen

Michael Chen — Wed, 30 Sep 2009 11:58:50 +0000

呵呵，当然欢迎了。但是，软件技术是一回事，作为组织由此产生的盈利是另外一回事。很多组织笼罩在盈利能力的光环下，所谓一俊遮百丑，由此之下的过程、工具、技术往往就不够看；而另一方面，一些有想法、过程优秀的公司，却规模大不了……这世界永远都这么公平。

By: Stephen. H. Wang

Stephen. H. Wang — Wed, 30 Sep 2009 02:24:04 +0000

Will your company accept human like me?

By: Stephen. H. Wang

Stephen. H. Wang — Wed, 30 Sep 2009 02:23:18 +0000

严重同意！
Pair-Programming不就是减少Code-Review – Re-Review的工时的方法吗？

Inline checker不也是辅助检查并减少code问题的有效工具吗？

感慨！一方面，这世界上有些人在努力地变革，寻求更好的方法来解决现实中的问题。另一方面，有些人在因循守旧，并且将勇于变革视为毒草猛兽。扼杀创新。

准备跳了。

By: dreamhead

dreamhead — Tue, 29 Sep 2009 15:45:31 +0000

看来你在大公司混得时间短，经受的催残少。:)

正经的。这里的Code Review，和我们理解的Code Review稍有差别。所谓专家，看的是业务上有没有遗漏，对于代码的Bad Smell很少嗅到，或是容忍度太高，根本没有人知道好代码应该是个什么样子，这才让代码的味道越来越大。