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

我和你的意思并不矛盾，我也认为“能够产生效益的技术才是真正有用的技术”。

但是，我追求的是：能够量化的评价标准。
我考虑的方向是“节约成本带来的效益”。你考虑的方向可能是“增加收入带来的效益”。对于一个尚未投入市场的产品或者技术，节约的部分是有可能量化的，而收入的多少，往往并不只是取决于技术本身，更加难以量化。

依照这个技术带来的“收入”，来评价这个技术，有可能会有“成王败寇”的偏颇。

关于效率那一段评论，怎么看怎么都对。

但是要开发效率高，代码就要少，分层就要少，越直接代码越少，首次开发效率就越高。。。。

这样如果是生命周期长的产品，维护效率就低，扩展效率就低。。。

可扩展和易维护有时候是和阶段开发效率有些时候是背道而驰的，所以，为了求得总的开发效率最高，在阶段开发效率，扩展性，。。需要折中。

笼统的说效率代码因改怎样，听起来不错，但对真正的开发没有什么帮助。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
或许，我们说的两个问题，你所针对的是那些维技术论者的忠告，而我只是对表达上的补充。：）

嗯，又觉得这的题目“定论——软件开发的评价标准(1) ”总是会有很多个人喜好在里面。

务实的人，关注效率，能否产生经济效果。
爱美的人，学术味道浓的人，喜欢把代码写的“美”一点，多花点时间，多用点框架，在所不惜。。。。

庄，我觉得我们与其讨论这些稍嫌空泛的概念，不如去找一些真正能帮助开发人员提高开发效率的好的工具，然后教会大家使用这些工具。比如我发现 Ant 能做的事情 Maven 都能做，而且 Maven 做这些事情的效率确实比 Ant 要高。
《人月神话》的最后好象布老的看法也是不能低估这些小的工具的价值，虽然在短期内（估计是三五年内吧）没有可能产生一种技术使开发效率有一个数量级以上的提高，但是如果善用这些小的工具，积累起来的开发效率提升也是很显著的。
另外还有人的因素，这些因素构成了开发成本很大的一部分，而且这些因素是不大可能由于采用新技术而消失的。这些在《人月神话》中都有明确的说明。

所以嘛，咱们等庄兄写完了再说^_^


咱们两方面的观点都要看，一个也不能少，嘿嘿

呵呵，楼上的，
如果两者不可兼得呢？。。。。。

嘿嘿，如果冲突，我选择前者。再说了，我也不认为有的东西（那些学院派的代码）就美。

＝＝＝
btw，说点使用fileupload和jspsmartupload的感受，后者简单易用好懂，前者学术味道就有点浓，对于用户来说，不知道设计者引入factory,base...之类的词有什么好处。。。。诸如此类设计模式的痕迹体现在在最终接口上实在是没有必要。

我是这样说的：道可，道非，常道。而你说的交流的问题，我名之为行话（不知道怎么回事cockburn也用这个词）。
其实庄表伟阐述的一个重要的概念－－量化。我最近有在研究用例点，不过似乎情况和前些年的情况还是一样，用例点依然是需要和我们的经验估算进行比对才有价值。我想对于这里说的评价体系依然会有这个问题。
对于代码的数量，我想你和我都是年纪比较大的，所以知道一些他们不知道的旧闻。记得当年有个《代码最佳效率奖》，似乎每一年一次，得奖的很多都是东欧和芬兰的人。不过那个效率只是用最少的代码显示最多的运算。当然ASM界还有一个奖－－最佳demo奖，就是在32k或者64k的代码中作一段非常炫目的动画。这些无疑都是很要命的技术，既要编码者的命，也要看编码者的命。
在我们的blog上我阐明了，面向对象的设计带来的类的数量不是更多也不更少，而是面向接口的DIP会更多，面向组合会更少。而代码的数量我想也是一样。同时增加代码的可阅读性，会让有些代码的数量增加，也会让有些代码的数量变小，这里有一个大家共同遵守的代码风格约束的问题。而当我们共同遵守这个风格的时候，代码的数量也未必就是越多就越不好，还有一个是否能够更好的显示编码者意图的问题，也有是否能够更好的带来结构的可复用的问题（主要是只代码的项目中复用，而不是项目间复用）。保持类的单一职责，无疑会使类的粒度变小，这样代码的数量，我看多数情况下会增加，而不是减少。而作为java语言来说，我想还有一个问题是一个类一个文件，而一个组合至少要用到两个文件。
所以我对于庄表伟的关于代码数量的是判断标准的言论不表示认同。而这一点在我的blog中的关于足采的投柱水平的判断的言论中就已经表明了我的态度，即使是只有一个基础的数据来源，我也要建立多个评价的体系。
所以至少现在我们还是要说：具体问题，具体分析。

对于商业公司而言，效益是第一位的，没有任何公司愿意投入大把的钱让你编造完美的代码。

如果能够满足客户需求，即使使用的技术非常陈旧，采用的架构非常粗陋，这个项目仍然是一个成功的项目。

不过话又说回来，是否采用一项新的技术，很多时候着眼点也并不仅仅在于一个项目的效益，而在于是否能在可接受的范围内推动公司技术的更新和发展。

作为一个合格的 PM，大多是一些比较保守的人。不会今天听说一种新技术，明天就决定马上用起来。总要自己先搞清楚，确信这种技术所能带来的利益然后才会做出决定。所以每当我把手头的工作暂时放下去研究某种新技术时总是有一种很强烈的紧迫感，担心自己不能在预定的时间内研究清楚。而我的时间又不多，常常是最多只能分配 3~4 天的时间去做这些研究，而且绝大多数都是在业余时间，晚上不加班，早点回到家里看这些资料。如果这种技术要花费我多于两周的时间，那我只能暂时先把它搁置在一边了。我还有更重要的事情要去做，说的俗点就是 make profit。现有技术可以做到，我就犯不着去冒这个险尝试新的技术。新技术我只会用在规模很小，时间比较充裕的项目中。
我要为之负责的不仅仅是我一个人，还有跟着我奋战的兄弟们。我并不想用太多的新技术使他们终日加班。象 XP 那样每周工作 40 小时而又能按时完成项目才是我最终的理想。

这些代码往往是由高级语言编写之后，在编译的过程中进行尽可能的优化，优化的目的就是执行效率，用最少的文本段来实现整个程序。而且更多的一些就是一大堆机器代码。千万不要想象他们真的是一行一行code出来的，不过在编译的过程中才是体现真功夫的时候，要对CPU的指令集要有比较深的了解。