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

46顶
8踩

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

编程

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

下面的就是软件编程中的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 条请登录后发表评论

53 楼 flyfly98 2010-10-09 08:59

szwx855 写道

18. 一个程序至少会完成90%，但永远完成不了超过95%。

3天通宵完成价值40万的10个功能，或许你才知道这句话的意思。

楼主啊，我不懂这句话的意思哦，请给我解释一下啦！

52 楼 jbon 2010-10-08 14:22

coolspeed 写道

引用

任何一个小程序里面都有一个巨大的程序蠢蠢欲出。

这个太科幻了。。

这个是说不要轻视任何一个小程序，小程序也许会孕育一个巨大的程序。

51 楼 marc0658 2010-10-08 11:06

"任何自己的程序，几个月不看，形同其他人写的。 "
呵呵，这是个存在的事实。跟编码规范关系不大。

50 楼 heroes3x 2010-10-08 09:05

让我看的内流满面。。道出了我不为人知的心声

49 楼飞语001 2010-10-07 13:25

这些规则属于开发人员的常识，一些基本的规则。

48 楼浪客剑心 2010-10-05 21:28

Gorehowl 写道

color=red]15. 编码开始的越早，花费的时间越长。[[/color]
顶一个~

这个也深有同感！

47 楼浪客剑心 2010-10-05 21:27

任何自己的程序，几个月不看，形同其他人写的。
---------------
深有同感！

46 楼 szwx855 2010-10-05 18:20

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

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

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

　从技术选型的角度来看，成熟的技术方案十有八九都不是最新颖的。而最新颖的十有八九都因为存在这样那样的问题而处于不断的演进中。因此，当我们完成一个系统时，它就已经陈旧了。
   2. 修改需求规范来适应程序比反过来做更容易。

        程序随着需求去变化，需求越多，改造越多，程序就越复杂，所以要想改变很小，尽量的稳定，改造文档比你改造程序简单。
   3. 一个程序如果很有用，那它注定要被改掉。

       需求扑天盖地，你想稳定那是不可能的。需求永远在变化，你只能改掉。
   4. 一个程序如果没用，那它一定会有很好的文档。

       而当一个程序没有文档时，要么这个程序只有你自己一个人维护，要么替换它的程序已经接近完成了。
   5. 任何程序里都仅仅只有10%的代码会被执行到。

       正如一个人写的代码最多只有20%是有效的，而偏偏其他80%的代码还无法或缺
   6. 软件会一直膨胀到耗尽所有资源为止。

       需求越来越多，甲方越来越讨厌。直到满足他们的所有要求时，才发现内存要扩容了、硬件要升级了、环境要更新了。。。
   7. 任何一个有点价值的程序里都会有至少一个bug。

       当你修正1个BUG,会引起另一个BUG的产生，在优秀的程序也会有BUG，越久发现的BUG，越是致命的。
   8. 原型完美的程度跟审视的人数成反比，反比值会随着涉及的资金数增大。

       模型越完美、功能越强大，系统开销就越大，当你设计的产品太复杂，往往后续要花指数级的倍数去维护，耗人力、物力、以及N多工作量，所以，这就是为什么很多开发人员提倡的：越简单越好。
   9. 软件直到被变成产品运行至少6个月后，它最严重的问题才会被发现。
       越严重的问题，往往到最后才知道。人不是电脑，百密一疏。
10. 无法检测到的错误的形式无限多样，而能被检测到的正好相反，被定义了的十分有限。

        当你检测到了一个错误，或许这个错误的背后也是个错误。
11. 修复一个错误所需要投入的努力会随着时间成指数级增加。

　     事实上每当我们修好三个bug的时候，往往我们会制造至少一个新的bug。
12. 软件的复杂度会一直增加，直到超出维护这个程序的人的承受能力。

         所以，甲方是有责任的。
13. 任何自己的程序，几个月不看，形同其他人写的。

         还会写c版本的helloworld么。
14. 任何一个小程序里面都有一个巨大的程序蠢蠢欲出。

         在强大的系统，也是由01组成的，在强大的逻辑，也有if..else.
15. 编码开始的越早，花费的时间越长。

        瞧瞧微软？
16. 一个粗心的项目计划会让你多花3倍的时间去完成；一个细心的项目计划只会让你多花2倍的时间。

        离职的人员写了一大堆垃圾代码，设计了一个垃圾功能，往往是你在后面给他擦屁股。
17. 往大型项目里添加人手会使项目更延迟。

        曾经看到软件设计原则中，人，要简而精，缩短经费，缩短开发周期。
18. 一个程序至少会完成90%，但永远完成不了超过95%。

       3天通宵完成价值40万的10个功能，或许你才知道这句话的意思。
19. 如果你想麻烦被自动处理掉，你得到的是自动产生的麻烦。

        你会猜测这个BUG不是自己引起的，并且相信自己的代码健壮性。可是，在你睡觉的时候，往往会接到公司电话，因为，你的代码在呼唤你。
20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。
         每次我和客户谈话，他们都说你设计的系统，一定要把我们假设为傻瓜，然后客户会向我演示一个傻瓜会如果去使用这个软件。

　　而每次我真的按照这样的元则来设计系统的时候，我自己总是被客户当做傻瓜。
    　于是我才知道，客户在使用他会使用的功能是，总是期待这个功能能做的足够灵活，最好每一步的行为都可以被用户临时改变。而当客户在使用他不会使用的功能是，却总是期待这个功能做的足够傻瓜，只要点击下一步，就一定可以到达目的地，而客户自己什么都不用做，什么都不用想。
　　问题却在于不同的客户关心的功能不一样，不同的客户会使用的功能也不一样。所以我们的系统易用性从来都没能达到客户的期待过。 21. 用户不会真正的知道要在软件里做些什么，除非使用过。
做需求的启示：永远不要期望能一次性彻底地搞清楚用户的需求。一种值得提倡的方法是:先了解能了解到的用户的需求，把软件做出来，提供用户反馈的渠道，在后续的版本中不断改进。

45 楼 luhaitao_2008 2010-10-05 15:37

嗯，真是不错，编程世界的定则啊

44 楼麦蒂粉丝 2010-10-05 15:10

那xp系统算不算是傻瓜式的呢？

43 楼 aimicheng 2010-10-05 08:39

Frederick 写道

引用

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

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

英雄所见略同。

42 楼 sunday1207 2010-10-04 22:12

引用

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

文档比代码本身更为重要，这点有点不认同

41 楼 coolspeed 2010-10-04 19:03

引用

任何一个小程序里面都有一个巨大的程序蠢蠢欲出。

这个太科幻了。。

40 楼 tianice 2010-10-04 08:47

不错，很中肯

39 楼 diandian 2010-10-04 00:30

Frederick 写道

引用

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

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

Frederick 写道

引用

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

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

解释的很经典！

38 楼 diandian 2010-10-04 00:25

Frederick 写道

引用

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

从商务的角度讲，正是因为如此，我们的合同才有了二期三期四期五期，我们的饭碗才得以保住。

Frederick 写道

引用

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。

每次我和客户谈话，他们都说你设计的系统，一定要把我们假设为傻瓜，然后客户会向我演示一个傻瓜会如果去使用这个软件。
而每次我真的按照这样的元则来设计系统的时候，我自己总是被客户当做傻瓜。
于是我才知道，客户在使用他会使用的功能是，总是期待这个功能能做的足够灵活，最好每一步的行为都可以被用户临时改变。而当客户在使用他不会使用的功能是，却总是期待这个功能做的足够傻瓜，只要点击下一步，就一定可以到达目的地，而客户自己什么都不用做，什么都不用想。
问题却在于不同的客户关心的功能不一样，不同的客户会使用的功能也不一样。所以我们的系统易用性从来都没能达到客户的期待过。

入门傻瓜化（基本功能）、深入灵活性（组合功能） +详细的操作说明书。

37 楼 luckeast 2010-10-03 23:37

一个程序如果没用，那它一定会有很好的文档。
有用的程序没必要写好的文档
只有没有的程序才要把文档写好
程序员就是为程序而生，不为文档而生
真理啊，以后得写少点文档，写多点有用的程序

36 楼 chrislee1982 2010-10-03 20:22

好多都是至理名言啊

35 楼 Frederick 2010-10-03 18:27

引用

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。

34 楼 Frederick 2010-10-03 18:16

引用

从商务的角度讲，正是因为如此，我们的合同才有了二期三期四期五期，我们的饭碗才得以保住。

发表评论

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

46顶8踩