软件设计法则

就像任何其他工程设计一样，软件设计也需要大量的努力，经验，耐心和专业知识才能正确完成。

根据Akin的《航天器设计定律》，我向读者介绍了一些我认为是基本的“软件设计定律”的细微修改清单，尤其是在处理面向客户的“量身定制”的软件产品解决方案时。

因为这被认为是“基本”清单，所以让我澄清一下，我们非常欢迎您提供自己的经验和意见。 因此，让我们开始...

1. 软件设计是用数字完成的。 没有数字的分析只是一种意见。
2. 正确设计软件产品需要付出无数的努力。 这就是为什么将它们设计为在出现某些问题时可以运行的好主意。
3. 设计是一个反复的过程。 必要的迭代次数比当前完成的次数多一。 在任何时间点都是如此。
4. 您的最佳设计努力将不可避免地在最终设计中毫无用处。 学会忍受失望。
5. （米勒定律）三个点确定一条曲线。
6. （马氏定律）如果用胖魔术标记画出对数对数，则一切都是线性的。
7. 在开始任何设计工作时，最想成为团队领导者的人最不可能做到。
8. 在自然界中，最佳状态几乎总是在某个地方的中间。 不信任断言最优是在极端点。
9. 没有您需要的所有信息永远不会成为不开始分析的令人满意的借口。
10. 如有疑问，请估算。 在紧急情况下，请猜测。 但是，请务必在实数出现时回去清理混乱。
11. 有时，到达终点的最快方法是扔掉所有东西并重新开始。
12. 从来没有一个正确的解决方案。 但是，总会有多个错误的地方。
13. 设计基于需求。 设计某种比需求所要求的“更好”的东西是没有道理的。
14. （爱迪生定律）“更好”是“好”的敌人。
15. （Shea定律）改进设计的能力主要发生在界面上。 这也是将其拧紧的主要位置。
16. 之前做过类似分析的人并没有直接接触到时代智慧的渠道。 因此，没有理由相信他们对您的分析。 尤其没有理由像您一样介绍他们的分析。
17. 过去的经验非常适合提供现实检查。 但是，太多的现实会注定原本不值得的设计。
18. 您比本领域的其他任何人都聪明得多的可能性很大。 如果您的分析表明终端速度是光速的两倍，则可能是您发明了翘曲驱动器，但搞砸了，机会要大得多。
19. 糟糕的设计和良好的外观最终注定要失败。 外观设计不佳的好设计马上就注定了。
20. （拉拉比定律）您在教室里听到的所有东西都是垃圾。 教育正在弄清楚哪一半是哪一半。
21. 如有疑问，请记录。 （程序终止后不久，文档要求将达到最高。）
22. 您制定的时间表似乎是虚构的完整作品，直到您的客户因不满足而解雇您为止。
23. 之所以称为“工作分解结构”，是因为除非您对分解结构强制实施，否则剩余的工作将一直增长，直到您有了分解。
24. （鲍登定律）在测试失败之后，总是有可能完善分析以表明您一直以来确实具有负边距。
25. （蒙泰梅罗定律）不要傻傻。
26. （瓦西定律）时间表只能沿一个方向移动。
27. （ 海因林定律 ）没有免费的午餐之类的东西。
28. （von Tiesenhausen的计划管理法则）要获得最终计划需求的准确估算，请将初始时间估算值乘以pi，然后将成本估算值的小数点向右滑动一位。
29. （冯·铁森豪森的工程设计定律）如果要对新软件系统的设计产生最大影响，请学习绘图。 工程师总是在设计车辆时看起来像最初的艺术家的概念。
30. （莫氏的进化发展定律）不能通过爬上更高的树木登上月球。
31. （阿特金演示定律）当硬件运行正常时，真正重要的访客不会出现。
32. （帕顿程序规划法则）现在猛烈执行的好的计划比下周的完善计划要好。
33. （罗斯福的任务计划定律）尽自己所能，随身携带。
34. （德圣埃修伯里的设计法则）设计师知道，他实现了完美，不是没有剩余的东西，而是没有剩余的东西。
35. 任何普通的工程师都可以设计出精美的东西。 优秀的工程师会设计出高效的系统。 优秀的工程师将其设计为有效的。
36. （亨肖定律）成功完成一项任务的关键是要建立明确的责任界限。
37. 无论系统工程教科书怎么说，能力都会驱动需求。
38. 如果您想保持负担得起的新有人值守计划并按计划进行，请不要重新发明轮子。

希望你喜欢

贾斯汀

相关文章 ：

• 每个程序员都应该知道的事情
• 2010年JavaCodeGeeks的10大热门帖子
• Java最佳实践– Vector vs ArrayList vs HashSet
• Java最佳实践–字符串性能和精确字符串匹配
• Java最佳实践–高性能序列化
• Java最佳实践–多线程环境中的DateFormat

翻译自: https://www.javacodegeeks.com/2011/01/laws-of-software-design.html