【外刊IT评论】软件编程21法则

46顶
8踩

2010-09-30 10:20 by 见习记者 songfantasy 评论(53) 有14690人浏览

编程

任何一个有经验的程序员都知道，软件开发遵循着一些不成文的法则。然而，如果你不遵循这些法则也并不意味着会受到惩罚；相反，有时你还会获得意外的好处。

下面的就是软件编程中的21条法则：

   1. 任何程序一旦部署即显陈旧。
   2. 修改需求规范来适应程序比反过来做更容易。
   3. 一个程序如果很有用，那它注定要被改掉。
   4. 一个程序如果没用，那它一定会有很好的文档。
   5. 任何程序里都仅仅只有10%的代码会被执行到。
   6. 软件会一直膨胀到耗尽所有资源为止。
   7. 任何一个有点价值的程序里都会有至少一个bug。
   8. 原型完美的程度跟审视的人数成反比，反比值会随着涉及的资金数增大。
   9. 软件直到被变成产品运行至少6个月后，它最严重的问题才会被发现。
10. 无法检测到的错误的形式无限多样，而能被检测到的正好相反，被定义了的十分有限。
11. 修复一个错误所需要投入的努力会随着时间成指数级增加。
12. 软件的复杂度会一直增加，直到超出维护这个程序的人的承受能力。
13. 任何自己的程序，几个月不看，形同其他人写的。
14. 任何一个小程序里面都有一个巨大的程序蠢蠢欲出。
15. 编码开始的越早，花费的时间越长。
16. 一个粗心的项目计划会让你多花3倍的时间去完成；一个细心的项目计划只会让你多花2倍的时间。
17. 往大型项目里添加人手会使项目更延迟。
18. 一个程序至少会完成90%，但永远完成不了超过95%。
19. 如果你想麻烦被自动处理掉，你得到的是自动产生的麻烦。
20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
21. 用户不会真正的知道要在软件里做些什么，除非使用过。

来自: 外刊IT评论

分享到：

46
顶

8
踩

评论共 53 条请登录后发表评论

33 楼 Frederick 2010-10-03 18:13

引用

11. 修复一个错误所需要投入的努力会随着时间成指数级增加。

事实上每当我们修好三个bug的时候，往往我们会制造至少一个新的bug。

32 楼 Frederick 2010-10-03 18:11

引用

5. 任何程序里都仅仅只有10%的代码会被执行到。
----只有10%的代码被执行到并不意味着其他的代码可以没有，其他代码多是处理的异常错误，只是执行的概率很小。

正如一个人写的代码最多只有20%是有效的，而偏偏其他80%的代码还无法或缺

31 楼 Frederick 2010-10-03 18:09

引用

4. 一个程序如果没用，那它一定会有很好的文档。

而当一个程序没有文档时，要么这个程序只有你自己一个人维护，要么替换它的程序已经接近完成了。

30 楼 Frederick 2010-10-03 18:07

引用

3. 一个程序如果很有用，那它注定要被改掉。

用户永远都会在你满足他们之前提出的需求时发现更多的需求。

29 楼 Frederick 2010-10-03 18:05

引用

1. 任何程序一旦部署即显陈旧。

从技术选型的角度来看，成熟的技术方案十有八九都不是最新颖的。而最新颖的十有八九都因为存在这样那样的问题而处于不断的演进中。因此，当我们完成一个系统时，它就已经陈旧了。

28 楼 Frederick 2010-10-03 18:02

引用

修改需求规范来适应程序比反过来做更容易。

深有同感。
所以需要我们深入分析用户提出的需求到底是想达到什么目的。有时候，可以走一条略微不同的路到达同一个目的，但是其途径往往更易于实现。这就是需求分析人员的价值所在了。

27 楼 Frederick 2010-10-03 18:00

引用

7. 任何一个有点价值的程序里都会有至少一个bug。

没有价值的程序，程序本身就是一个超级大bug。所以，自然人写出来的程序，不可能没有bug。

26 楼 Frederick 2010-10-03 17:58

引用

15. 编码开始的越早，花费的时间越长。
----编码开始的越早，对需求的理解就越少。这时候急于编码结果是写的是不符合需求的程序，必须修改或重写，因而花费的时间越长。

还有一个重要原因，在于越早开始编码，意味着越少的设计。结果就是导致编码时间变长了。

引用

17. 往大型项目里添加人手会使项目更延迟。
----越多人，开个讨论会议也会越长

越多人参与，培训时间越长，协调时间越长，人均效率就越低。但是这是有一个临界点的。当一个项目不能满足必要的人数时，增加人数利大于弊。而当人浮于事的时候，人数越多，效率越低。

25 楼 kx29126390 2010-10-03 10:37

有的法则不错，有的不知所云

24 楼 wenty09 2010-10-02 13:39

是( ⊙ o ⊙ )啊！阿斯达克中国人奇强潘永昌中国人奇强哈啊哈
6月18号~

23 楼 huansinho 2010-10-02 13:16

tianmo2008 写道

huansinho 写道

12. 软件的复杂度会一直增加，直到超出维护这个程序的人的承受能力。
泪流满面

况往往是前人挖的坟墓，埋葬的却是后来的人。
替以后接手维护这个软件的人捏一半汗

我就是后来的人

22 楼 allenny 2010-10-02 00:46

求英文原版

21 楼 dream_mjs 2010-10-01 16:11

21条法则，但不同人站的立场不一样，看待的结果也会不一样，最终只能由软件本身的特殊性来决定哪些法则是适用的。

20 楼 liyaxi 2010-10-01 13:37

每一句都是金玉良言，金科玉律。

19 楼 aimicheng 2010-10-01 11:17

rocwon 写道

encro 写道

rocwon 写道

很多“法则”都已经OUT了

请举例说明

您觉得下面这些玩意算是“法则”么？
4. 一个程序如果没用，那它一定会有很好的文档。
----这句不太理解。

5. 任何程序里都仅仅只有10%的代码会被执行到。
----如此绝对的定论，那意味着90%的代码都可以砍掉？

15. 编码开始的越早，花费的时间越长。
----这是典型的瀑布思维下的结论。现实是：编码开始得越晚，则可能花费的时间越长

17. 往大型项目里添加人手会使项目更延迟。
----Brooks的原话是这样说的吗？

18. 一个程序至少会完成90%，但永远完成不了超过95%。
----为什么永远完成不了95%？，为什么又是“至少”？

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
----现在我们很多开发人员都太“聪明”了，开发出的软件连傻瓜都不愿意使用。

这些法则没有哪一条是绝对正确的，我觉得要放到特定的环境中去理解。

4. 一个程序如果没用，那它一定会有很好的文档。
----这句鬼话有点逻辑性可言么?

5. 任何程序里都仅仅只有10%的代码会被执行到。
----只有10%的代码被执行到并不意味着其他的代码可以没有，其他代码多是处理的异常错误，只是执行的概率很小。

15. 编码开始的越早，花费的时间越长。
----编码开始的越早，对需求的理解就越少。这时候急于编码结果是写的是不符合需求的程序，必须修改或重写，因而花费的时间越长。

17. 往大型项目里添加人手会使项目更延迟。
----大多数情况下是这样的。

18. 一个程序至少会完成90%，但永远完成不了超过95%。
----90%，95%并不能理解为绝对的数值。一个程序如果你把所有设计的功能都实现了那么可以认为是完成了90%，但是后续的维护工作使你永远无法100%的完成这个软件。

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
----这个我已经说明过。

18 楼 aimicheng 2010-10-01 11:03

引用

2. 修改需求规范来适应程序比反过来做更容易。

我相信许多程序员潜意识里都希望反过来做

引用

21. 用户不会真正的知道要在软件里做些什么，除非使用过。

做需求的启示：永远不要期望能一次性彻底地搞清楚用户的需求。一种值得提倡的方法是:先了解能了解到的用户的需求，把软件做出来，提供用户反馈的渠道，在后续的版本中不断改进。

17 楼 aimicheng 2010-10-01 10:55

luckeast 写道

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
----傻瓜都会用，聪明人也都变傻瓜了哈

这条给了我们关于软件可用性方面的启示：如果你把软件易用性做过了头，必将失去真正的用户。因为易用性做的太过的代价是过多的提示，过多的使用教程，很多显而易见的东西都说明了，这样的软件也只有傻瓜会用了。

16 楼 tianmo2008 2010-10-01 08:21

huansinho 写道

12. 软件的复杂度会一直增加，直到超出维护这个程序的人的承受能力。
泪流满面

况往往是前人挖的坟墓，埋葬的却是后来的人。
替以后接手维护这个软件的人捏一半汗

15 楼 luckeast 2010-10-01 02:50

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
----傻瓜都会用，聪明人也都变傻瓜了哈

14 楼 luckeast 2010-10-01 02:48

人手会使项目更延迟

rocwon 写道

encro 写道

rocwon 写道

很多“法则”都已经OUT了

请举例说明

您觉得下面这些玩意算是“法则”么？
4. 一个程序如果没用，那它一定会有很好的文档。
----这句鬼话有点逻辑性可言么?

5. 任何程序里都仅仅只有10%的代码会被执行到。
----如此绝对的定论，那意味着90%的代码都可以砍掉？

15. 编码开始的越早，花费的时间越长。
----这是典型的瀑布思维下的结论。现实是：编码开始得越晚，则可能花费的时间越长

17. 往大型项目里添加人手会使项目更延迟。
----Brooks的原话是这样说的吗？

18. 一个程序至少会完成90%，但永远完成不了超过95%。
----为什么永远完成不了95%？，为什么又是“至少”？

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
----现在我们很多开发人员都太“聪明”了，开发出的软件连傻瓜都不愿意使用。

4. 一个程序如果没用，那它一定会有很好的文档。
----一个程序如果没用，也没有很好的文档，就没有人认识到它没用

5. 任何程序里都仅仅只有10%的代码会被执行到。
----大型项目中的一次请求确实连百分之一的代码也没执行到

15. 编码开始的越早，花费的时间越长。
----这是真理，软件工程的课程上经常提到

17. 往大型项目里添加人手会使项目更延迟。
----越多人，开个讨论会议也会越长

18. 一个程序至少会完成90%，但永远完成不了超过95%。
----没有最完美，只有越完美

发表评论

您还没有登录,请您登录后再发表评论

46顶8踩