软件开发的基本法则

软件开发的基本法则

与任何其他学科一样，软件工程领域包含一些有趣且众所周知的规则、概念和法则。

墨菲定律
“任何可能出错的事情都会出错。”
可能是所有法律中最著名的法律之一，主要是因为它不仅适用于软件开发。

1. 第一个推论：如果它起作用，可能不是你写的。
2. 第二个推论：骂人是所有程序员唯一能说流利的语言。
3. 结论：计算机会做你写的东西，而不是你想做的。

防御性编程、版本控制、末日场景（针对那些该死的僵尸服务器攻击）、TDD、MDD等都是抵御这种法律的良好做法。

布鲁克斯定律
“为后期项目增加人力会使其更晚。”
Fred Brooks 于 1975 年撰写的神话人物月是 Brooks 定律的来源。它的运作前提是团队成员和所需的月数可以互换。这是不正确的，尤其是在开发软件（或任何产品开发，就此而言）时。为什么？由于需要时间来通知和更新项目的个人。

康威定律
“任何软件都反映了产生它的组织沟通结构。”
这条软件开发规则是梅尔文·康威在 1967 年提出的。产品设计与康威定律有关。通信架构对软件生产的影响是一个观察到的现象。
因此，一个紧密团结的团队齐心协力开发具有相互交织的功能和代码的软件。
与此同时，一个更松散、去中心化的团队会生产更多模块化的软件。

霍夫斯塔德定律
“它总是比你预期的要长。（即使考虑到霍夫施塔特定律。）”
软件开发中最担心的问题之一是“需要多长时间？” 霍夫施塔特定律给出了解释。
这与另一条被称为帕金森定律的规则有关，该定律指出，工作会扩大到占用完成它所需的所有时间。由于帕金森定律和霍夫施塔特定律，很难预测完成时间。

莱纳斯定律
“只要有足够的眼球，所有的bugs都是浅的。”
这一定律是用著名的《大教堂与集市》一文来描述的，解释了两种不同的自由软件开发模式之间的对比。

• 大教堂模式，在这种模式下，每一个软件版本都有源代码，但在两个版本之间开发的代码只限于一个专属的软件开发者群体。
• 集市模式，在这种模式下，代码是在公众的视野中通过互联网开发的。

结论是什么？
源代码越广泛地提供给公众测试、审查和实验，各种形式的错误就越快被发现。

古德哈特法则
"当一个措施成为一个目标时，它就不再是一个好的措施"。

古德哈特定律在软件开发中的一个例子是代码行。代码行提供了一种衡量软件产品规模的方法。但是，当被用作目标时，代码质量就会下降。本应需要精炼或从软件中删除的行，反而被建立起来，形成一盘混乱的意大利面条代码。

Gall盖尔定律
"一个有效的复杂系统是由一个有效的简单系统演变而来。一个从头开始建立的复杂系统不会工作。"

盖尔定律，如果它成立的话（似乎是这样的），是以最小可行产品（MVP）开始软件产品开发的一个好理由。

Zawinski定律
"每个程序都试图扩展，直到它能阅读邮件。那些不能扩展的程序会被能扩展的程序所取代"。

说到复杂性，扎温斯基定律表明，产品一旦建成，就会继续扩展。它们会增加更多的功能领域，直到它们无法再扩展为止。功能蠕变的例子说明了软件开发中的扎温斯基定律。臃肿的程序很快就会被放弃，转而选择更精简的方案。

伊格利森定律
"任何你自己的代码，如果你有6个月或更多的时间没有看，可能还不如别人写的好。"

许多人认为Eagleson是个乐观主义者--认为6个月是一个慷慨的时间框架。不管怎么说，Eagleson的法则强调了清晰、有效的评论和明确的编码标准的必要性。毕竟，即使是原来的程序员也无法在以后的工作中破译混乱的代码。

卢巴斯基定律
"总是有一个更多的错误。"

最后，对于你所有的编程最佳实践、更新和维护，总是有一个更多的错误要修复。或者还有一件事需要调整，或者增加，或者学习。毕竟，程序员的工作是永远不会完成的。所以，请记住，当涉及到软件开发时，完成总比完美好。

九十法则
"前90%的代码需要10%的时间。
剩下的10%需要另外90%的时间！"

克努特的优化原则
"过早的优化是万恶之源！"

如果你试图在优化时考虑到未来的状态，试图考虑到未来的边缘情况，那么你就会在本质上不断增加系统本身的解决方案的复杂性，同时甚至不能正确地知道未来的问题状态到底会是什么。