另外，也可以找一个叫laws-of-software的网站，同样也在搜集软件开发的定律。
本文翻译自toward data science上Semi Koen发表的文章，该文章对这些定律进行了较好的归类，方便研究，本文将按照原作者的分类依次展示这些定律。
关于技术“我们往往高估技术在短期内的影响，而低估了长远的影响”。
（图片来自网络侵删）--Amara's Law
译者注评：
是对Gather发布的技术炒作曲线（The Hype Cycle）的一个概括性描述。技术炒作曲线表明，在新技术刚出现时，其潜在影响通常让人们激动和兴奋，人们会迅速投入进去。这时，由于技术还不够成熟等因素，又常常会对结果感到失望。经过一段时间后，技术的能力会发挥出来，实际应用的机会也会增多，应用者最终会变得富有成效。这条定律告诉我们任何时候都要把眼光放长远一些，向前看。
技术炒作曲线
“任何足够先进的技术都与魔法无异”
--Clarke's Third Law
译者注评：
本定律由英国科幻作家和未来学家阿瑟·克拉克撰写，是他关于技术和发现本质的观察。
克拉克第一条定律是："当一个杰出但年迈的科学家说有些事情是可能的，他几乎可以肯定是对的。当他说某事是不可能的，他很可能错了。“
克拉克第二条定律是："发现可能的极限的唯一方法是冒险从这些极限中超越一点，进入不可能的极限。”
克拉克的第三条定律是最著名的，就是本条。
克拉克总结说："由于三部定律对牛顿来说已经足够好了，我谦虚地决定就此止步”
C. Clarke
“机构会努力保留那些它们拥有解决方案的问题”
--Clay Shirky
译者注评：
Shirky定律揭示了这样一种现象：那种复杂的解决方案，包括一家公司，一个行业，或一项技术，可能会过于专注于它们正在解决的问题，以至于它们可能会在“无意中”让问题永久存在下去。
究其背后的原因，一方面可能是出于证明继续当前解决方案是合理的，有意而为之。另一方面，可能是无法或不愿意接受另一个能够完全消除问题的解决方案，这基本是下意识的。
管理者显然不想让员工将车的所有问题解决掉
“我们这个行业有一件奇怪的事情：我们不仅没有从错误中吸取教训，而且我们也没有从成功中吸取教训”
— Keith Braithwaite
译者注评：
反正我们就是不长记性。
Keith Braithwaite名言
关于编程“提高使用资源的效率会增加该资源的使用率”
-- Jevon's Paradox
译者注评：
“路修得越宽，跑的车越多”，应该是同一个道理，这个现象也叫“布雷斯悖论”，德国数学家布雷斯在60年代提出：在一个交通网络上增加一条路段，反而会使网络上的通行时间增加。
“如果你自动化了一个烂摊子，你就会得到一个自动化的烂摊子”
--Rod Michael
译者注评：
自动化本身不是来帮助我们解决混乱的，避免进入这种很容易就有的错觉
“一个好的程序员在走单行道之前总是看着两边”
--Doug Linder
译者注评：这也是关于程序员的5个笑话之一，当笑话讲时，可以翻译为：“当程序员走在单行道上时，也总是左顾右盼”。它告诉我们，唯一的确定性就是不确定性，不是每个人都会遵循单行道的规则，作为程序员，不能对程序中事物的行为作出假设，必须总是检查一切。
要注意看向两边
“任何你写过的代码，当过了6个月或更长时间再看时，感觉就像别人写的”
--Eagleson's law
译者注评：
所以，代码是写给“别人”看的，包括6个月后的自己
理想情况是6个月，实际是3周
“一个人的烂软件是另一个人的全职工作”
--Jessica Gaston
译者注评：
当我们的代码或软件很烂时，伤害的包括一起开发的同事，后续的测试同事，还有最终用户。
关于编写无错误代码“最便宜、最快、最可靠的组件是那些不存在的组件”
--Gordon Bell
译者注评：
最好的代码是还没有写的代码，最好的组件是不存在的组件。
大河弯弯向东流，就是这么牛。
“如果调试是去除Bug的过程，那么编程一定是将它们放入的过程”
--Edsger W. Dijkstra
译者评注：
代码无法覆盖一切情况，Bug伴随代码而产生，我们所做的就是尽量减少它，尤其是避免在修复Bug时引入更多Bug，出现“我有1个Bug，修复了1个Bug，最终收获了2个Bug”的现象。
避免引入更多Bug
“删除的代码就是调试的代码”
--Jeff Sickel
译者注评：
少即是多，我们可以通过添加新代码来改进系统，也可以通过删除代码来改进系统，真正的好代码就是不存在的代码，是代码外的解决方案，美因简单而美，去掉那些无用的代码、死代码，问题就会随之而去。
删除代码的感觉真好，感觉一切都清净了
“虫子潜伏在角落里，聚集在边界上”
--Boris Beizer
译者注评：
一语双关地指出了Bug总是出现在那些我们极少关注到的地方，两者的想通之处不得不让人赞叹。
“世上有两种方法可以写出没有错误的代码，而只有第三个是有效的”
--Alan J. Perlis
译者注评：
这话说得多明白啊！
代码调试的循环
关于架构与设计“雇人编写代码来销售与雇人设计和构建耐用、可用、可靠的软件不同”
--Larry Constantine
译者注评：
有没有设计是不同的
“设计中最难的部分是舍弃功能”
--Donald A. Norman
译者评注：
设计就是权衡各方面因素，难在分寸的拿捏，而最难做到的就是狠心放弃某些功能。
“建立在脆弱架构之上的软件系统会被自己成功的重量压沉”
--The Archimedean Principle
译者注评：
缺乏设计的脆弱架构终将不堪重负。
“在软件可以重用之前，它首先必须是可用的”
--Ralph Johnson
译者注评：
为什么要强调这个？
“一个有效的复杂系统总是从一个有效的简单系统演化而来”
--Gall's Law
译者注评：
直接设计高度复杂的系统很可能会失败，互联网是高度复杂的，是随着时间的推移而变得复杂起来的。
关于需求“如果两者都被冻结，那么在水上行走和从需求规格开发软件都是很容易的”
--Edward V Berard
译者注评：
软件开发的部分压力来自需求的变化和不确定性。
“在系统真正使用之前，用户永远不会知道他们想要什么（甚至在使用之后）”
--Humphrey's law
译者注评：
事实上，有很多原因会导致需求难以被定义。
敏捷开发方法的用武之地
“更改需求规格以适应程序比反之更容易”
--Alan Perlis
“一个需求被考虑得越稳定，它被改变的可能性就越大”
--Heisenberg's Principle
译者注评：
量子力学的不确定性原理表明，粒子的位置和速度不可同时被确定，位置的不确定性越小，则速度的不确定性越大，反之亦然。
很多人都在把量子力学的不确定性原理引入到软件开发领域，以解释一些现象。如内聚性，代码在结构上高内聚时，行为上却很发散。另一方面，按业务或按技术划分模块，也存在类似的张力，该观点见于chelsea的博客。
需求本身可能也存在类似性质，如果开始把需求做得看起来很确定的样子，实际上无形中在增加它剧烈变化的力量，导致其改变的可能性变得更大，整个过程像是在拉一张弓一样。
不确定性原理
“选择越多，做决定的时间越长”
--Hick's law
译者注评：
希克定律，深入影响到用户体验设计。
Hick定律在UX中的应用
Hick定律原理
“戴一块手表的人知道时间，而戴两块手表的人却难以确定时间。”
--Segal's law
译者注评：
有一句谚语，如果你说实话，又不得不再说一次时，你不必记住你是如何编造谎言的。在软件领域，要注意需求的一致性，避免让用户在矛盾中选择。
关于估算和时间管理“前面 90% 的代码占用了前 90% 的开发时间，而剩余 10% 的代码使用了另外 90% 的开发时间”
--Tom Cargill
译者注评：
这个又叫90-90法则，是对90%完成综合症的描述，这个现象指出，在对剩余工作量容易产生过度积极的估计，剩余10%的工作量更有可能编程另外90%的工作量。为此，有人提出采用0/100规则表示完成百分比，在未完成时，始终表示为0，直到真正全部完成，才表示为100，相对比较保守和可靠。也可类似地采用20/80或50/50法则。
90%综合症
团队成员对项目的兴奋感递减规律，可能是造成90%综合症的一种原因。
项目后期兴奋度降为零
“从现在到项目完成的时间趋于恒定”
--Hartree's Law
译者注评：
Hartree应该指的是英国数学家和物理学家，他提出了著名的Hartree–Fock方程，用于确定处于稳态的量子多体系统的波函数和能量。所谓稳态，就是一个量子态的所有观测与时间无关，系统随着时间的流逝，以各种可观察的方式保持在相同的状态。
将Hartree用到项目中，应该是讽刺那些永远剩余固定时间完成的项目，实践中应当避免掉入这种陷阱。
“工作会自动扩展以填补可用于完成的时间”
--Parkinson's Law
译者注评：
该定律原揭示官僚机构的工作特点，此处形容团队在截止日期临近之前表现为效率低下，而后又匆忙在截止日期前完成工作的现象，该现象很可能使实际截止日期延后。
“即使考虑到本条定律，所用时间也总是比您预期的要长”
--Hofstadter's law
译者注评：
我们往往会低估复杂任务的完成时间。
通过将任务分解为明确的小任务，专注于当前任务，避免遗留问题，避免刻意追求完美，这些时间管理技巧，可以帮助我们尽可能克服该定律。
“永远没有足够的时间把事情做对，但总有足够的时间重新做”
--Jack Bergman
译者注评：
我们总喜欢做新的东西，不是吗？
关于项目管理“为迟到的软件项目增加人力会使其更晚”
--Brooks's Law
译者注评：
通常，试图通过增加人手来加速已经延迟项目的交付，将会使交付更晚。其中原因可能是新资源带来的短期内沟通开销上升，以及任务的不可分割性等。
谚语“找齐九个妈妈，并不能实现在一个月就生出孩子”体现了类似的道理。
“对于许多现象，80% 的后果源于 20% 的原因”
--Pareto Principle
译者注评：
著名的帕累托法则。
帕累托法则
“没有什么是在计划内或在预算范围内建造的”
--Cheops' Law
译者注评：
参照Hofstadter's law
“任何可能出错的事情终将出错”
--Murphy's law
译者注评：
墨菲定律，不用过多解释。
“我一直觉得计划没用，但计划又是不可或缺的”
--Dwight D. Eisenhower
译者注评：
不是计划没用，计划不是这么用的。
你需要为失败的准备准备失败
后记定律都是有心人经过大量观察后总结出来的，一定有其背后深刻的原因。但是，有没有破局之道呢？我们终将被这些定律左右吗？我们是否可以利用这些定律呢？您心中是否已经有了答案呢？
