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. 用户不会真正的知道要在软件里做些什么，除非使用过。
做需求的启示：永远不要期望能一次性彻底地搞清楚用户的需求。一种值得提倡的方法是:先了解能了解到的用户的需求，把软件做出来，提供用户反馈的渠道，在后续的版本中不断改进。
22. 永远不要去猜想客户的需求。
当一个用户的需求不明确的时候，我们所需要做的不是在那里一群人在讨论客户的需求到底是啥，他们需要做成的是怎么样的；而是要直接了当的去问客户，知道他们的最真实的想法好过你凭空猜想浪费时间浪费钱。
2248
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
