[原创]定论——软件开发的评价标准(1)

一、序论

我们一直在争论，什么更好。
什么是更好的语言，什么是更好的写法，什么是更好的设计，什么是更好的风格，什么是更高的框架，什么更好的工具......

没有定论，似乎没有什么能够占绝对的上风，往就是陷入混战，边上还有人劝架：“具体情况具体分析嘛，这样凭空吵不出结果的！”

能不能得到定论呢？

首先要明确，标准是什么？或者说软件开发的根本目标，除了满足功能需求之外，对于软件开发的这一方来说，最重要的目标是什么？

————效率！
同样的软件开发收入，投入的成本越低，就越赚钱。
对于开发人员也这样，同样的项目，如果只用干一个月，而不是一年，同样的奖金数量，大家都会很开心。

一切有助于提高效率的，都是好的。
而一切妨碍效率的，都是坏的。

有些方法吹得神乎其神，你用了以后，发现没有提高效率，但是带来了别得好处。。。且慢，如果它降低了你的工作效率，那么它的任何好处都是假的。

有人告诉你，文档很重要，如何如何。你写出了世界上最漂亮的文档，但是你的开发速度是原来的1/10，那么你就是被这样的思路害了。

有人告诉你，代码分离很重要，然后你发现你经常需要修改文件，满足需求变更，都要跨越十几个文件，那么你又受骗了。

也许有人又告诉你，你这样的做法不符合那样的“最佳实践”。而你发现理解这些“最佳实践”，花费了你大量的时间，那么你还是受骗了。

真正好的东西，理解起来也应该很容易，学习起来也不会难，它是自然的。那些一看就觉得不自然的思路，你永远都不该去试图理解它，否则就是浪费了时间。


二、总开发成本
软件开发，基本上还是一个手工劳作的行业。软件开发的成本，基本上就是人员的工资×工作量。而得到的产品，就是一堆“byte”。包括“文本的byte”和“二进制的byte”。也就是“代码”＋“文档”＋“其他资源文件”。

如果我们把美工MM的工作忽略不记的话（罪过罪过）。总开发成本，就和整个开发期间的代码总生产量正比。（包括第一次写下来，后来又被删除的代码）因为基本上，一个人的代码生成数量，与他的工作时间成正比，也就进而和他的工资成正比。

要降低成本，其实就是要降低总的代码生产量。当然，前提是功能要保证能够完成，性能也不能低于客户的要求。

为什么不记美工MM的工作呢？这个需要解释一下
因为大多数时候，客户的修改需求都会围绕代码，而只会在项目的初期要求修改视觉效果。作为一次投入的成本，相对于整个项目的成本，实在不是很高，除非是“游戏”。另外一方面，在这个领域的提高效率的工具，向来没有什么太大的争论，甚至效率都不是第一要求考虑的因素。

回到我们的话题上来，我想要说明的就是：一切方法，设计，思路，技巧，如果不能切实的降低代码总数＋文档总数，那么他就是“害人”的东西。

——待续

精彩，期待下文

谢谢你的鼓励，也谢谢这么早就看出这会是一篇精彩的文章。
我一定会写完的，保证精彩！

我们要思考一个问题，技术在什么时候是有用的？好的技术对于企业未必是有用的，除非这种技术能够在第一时间转化为商业价值（比如：实现某种用户需要但是以前的技术很难实现的应用）。行百里者半九十。学会一种技术只是走了一半的路，把这种技术转化为商业价值（注意：还要在第一时间）才算是完成任务。
超链接无疑是很好的技术和思想，但是只有 Marc Andreessen 抓住了这个机会，第一时间建造出成功的商业软件 Netscape，于是他成功了，一夜之间成为了亿万富翁。
P2P 也是很好的技术和思想，但是现在创造出商业价值了吗？至少还没有创造出很多的商业价值。原因是它还没有很好地与商业相结合。
技术无所谓好坏，老的技术如果能实现相同的业务，而且开发效率更高，就是好的技术。某年轻人会用技术 A、B、C，把这些技术都用起来，完成一个项目需要用 6 个月时间，我只会用技术 A，但是因为我以前很重视技术积累，完成相同的项目需要用 3  个月时间，那么我就比这个年轻人对公司更有价值。技术 B 确实非常棒，但是如果学习成本很高，花费 3 个月时间才能掌握，然后再花费一年时间才能达到与原先相同的技术积累（开发框架、可重用组件），这样的 sink lost 值得吗？所以时间效益是需要认真思考的一个问题。自己创办公司的人思考问题和纯技术人员思考问题完全不是在一个层面上。
在当年 C++ 热潮中，大批软件公司用 C++ 重写自己用很多年写成的 C 代码，这样的大规模的 ado 得到回报了吗？ Much ado about nothing!

你说的“技术”和我说的“技术”，不是一个层面。

你说的，是能够“产业化”的技术。
而我说的，是能够辅助软件开发的技术。

而且在你的文字里，技术、思想、技巧，有点混淆。

是有点混淆。我觉得也没必要分的太清楚（道可道，非常道，你和我经验不同，我所理解的道也许不是你所理解的，我为什么要浪费时间和你争论呢？我完全不是一个做研究的人）。
我这段话的意思就是，能够产生效益的技术才是真正有用的技术。同样的技术对不同的人不一定都是有用的，除非他能以较低的成本掌握。比如你读过设计模式，我和你沟通起来成本很低，我一讲用 Singleton 你马上就明白了。可是对于一个根本没听说过设计模式的人，成本就高多了。再举个例子，很多人误以为 XP 倡导的就是简单，但是却不知道这种简单包含了多少高手之间的隐喻在里面。可以说是复杂之上的简单，而不是一味的简单。结果达不到与大师宣称的同样的效果，于是又开始骂娘。话扯远了，呵呵。

》能够产生效益的技术才是真正有用的技术
这话没错，问题是这是一个事后的标准，也就是说，是将技术应用之后，根据市场的反应所作的评价。这无疑是最权威的。但是，我们也需要一些在应用技术前对技术进行评估的的标准。

对开发者而言，“效率”是个很重要的因素，只是效率这个因素不好评估。庄兄文章还未写完，期待下文，呵呵

这就需要公司做好培训，确保开发人员对于这些日常使用的技术都有很好的掌握。很多公司不重视培训和技术积累，只能跟风，使用一些现成的开源软件。但是这些软件也有相当的复杂性（例如象 Hibernate、Spring 这样的开发框架），用的不好，就怪框架写的太烂，明天还是试试下一个框架，其实说来说去都是自己的问题。
不是所有的技术都要亲自用起来才能知道它是否能产生商业价值，那样你岂不是要累死？有经验的开发人员往往只需要看看这种技术的相关文档，以及跑到相关的论坛中看一看大多数使用者都用它来做什么就足以做出判断了。

>>有经验的开发人员往往只需要看看这种技术的相关文档，以及跑到相关的论坛中看一看大多数使用者都用它来做什么就足以做出判断了。

有经验的开发人员是如何下这个判断的，就是我们最想知道的啊

庄兄的帖子说的就是他是如何下这个判断的，是从技术角度，而dlee兄则是从人的角度

这又回到了我说的“道可道，非常道”那句话上了。你心里会说，这家伙不好好回答问题，跟我玩起了玄学了！可是很多时候经验确实不是很轻易地就能从一个头脑传递到另一个头脑的。我和我的朋友 ly 合作了一年多，其间因对技术问题的不同看法发生过数次争论，现在才比较充分地理解了他的很多设计意图。发现以前由于经验上的差距，未能理解他的设计，他的很多想法其实都是非常正确的。
我可以举出很多虽然很流行但是目前对于我们这个特定的开发团队短期内（我加了这么多限定词就是害怕引起争论，否则有人就会义正词严地驳斥道：EJB 不能产生商业价值，你不是又喝了两盅吧？）无法产生商业价值的技术——EJB、.Net、AOP、MDA......