我们已经向您介绍了您需要了解的最基本的编程原则，但是还有另一类编程原则可能比这些原则更有用。

上面提到的原则教你如何聪明地使用代码，下面的原则将教你明智地使用代码。其中有些是奇怪的，许多是幽默的，但他们都同样实用和重要。小心点！

1膨胀原理

这一个有太多的变化，很难选择一个作为主要的。也许最“官方”的版本是软件包络定律，更常见的称为Zawinski定律，以Jamie Zawinski命名，在UNIX编程艺术中提到：

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

它所说的是，随着时间的推移，程序会吸引越来越多的特性，并不可避免地向越来越复杂的方向发展。您可能知道这是一种特性爬行，它是不断添加的新特性，与程序的主要目的无关。特征蠕变导致膨胀，膨胀通常是不受欢迎的。

这也适用于软件性能：

"Software expands to c***ume all available resources."

早在90年代，硬盘驱动器、cpu和RAM的限制比现在要严格得多，程序员们努力工作，尽可能地在限制范围内进行调整。然而，现在我们有了更大的驱动器、更快的CPU和更多的RAM，我们仍然很难遵守限制。一切都会随着时间膨胀。你的工作就是控制住这一切。

2“越差越好”的心态

几乎就好像是对膨胀原则的回应，我们有一种“坏就是好”的心态，这是Richard P.Gabriel在一篇关于软件质量的文章中首次提出的：

"Software that is limited, but simple to use, may be more appealing to the user and market than the reverse."

换句话说，找出你的软件要解决的一个问题，然后在这一点上做得非常好是明智的。保持简单。你越分散精力，项目就越难以管理，用户就越不喜欢它。

当你忽略这个会发生什么？你最终得到了软件原理：

"A overly complex project will eventually become too complex to be understood even by its own developers."

它来源于更广泛的彼得原则，该原则规定，当员工根据其目前的能力而不是下一个职位的预期能力得到提升时，所有员工最终都会处于不称职的境地。把这个原则应用到软件中，你就会明白为什么越差的软件往往越好。

三。伊格尔森定律

"Any code of your own that you haven't looked at for six or more months might as well have been written by someone else."

这句看似让人泄气的话其实是值得接受的。事实是，没有人是完美的。你可能认为你现在是一个天才程序员，但总有更多的东西可以学，总有更多的发展空间。如果你回顾旧代码并畏缩，那可能意味着你从那以后学到了新东西。

换言之：如果你回顾一个老项目，你看不到任何可以改进的地方，也看不到下一次会有什么不同的做法，那么作为一个程序员，你很可能已经停滞不前了。

4最小惊奇原则

"If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."

这一原则于1984年首次发表在《IBM系统杂志》上，如今仍然出人意料地相关——也许比以往任何时候都更相关。

它本质上触及了创新和熟悉之间的微妙平衡：如果一个软件与同类软件差别太大，不符合用户的期望，那么他们很可能不会采用它。更好的做法是努力实现渐进式的改进，这些改进要大到足以让人印象深刻，但要小到足以让人耳熟能详。

5控制论昆虫学定律

"There's always one more bug."

通常被称为控制论昆虫学的卢巴斯基定律，不清楚这个卢巴斯基到底是谁。然而，他的原则对所有程序员来说都是正确的：不管你写代码多么干净，不管你测试模块多么健壮，不管你重构类的频率有多高，总会有另一个bug。

在某种程度上，这是一个自由的原则。虽然我们一定要争取无缺陷的代码，但同样重要的是要记住，完美主义是好的敌人。寻找错误，当它们出现时修复它们，然后继续前进。

6克尼根定律

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not **art enough to debug it."

布莱恩·克尼根（briankernighan）正是与人合著了《C编程语言圣经》（C programming language bible）的人，以这条有见地的定律而闻名。关键在于：写好代码，写可读代码，写简单代码，只要不是聪明的代码就行。

试图用象牙塔的复杂性来锻炼你的编程能力，与编写干净、更好的代码的意义恰恰相反。你的代码越难理解，当它不可避免地崩溃时，调试就越困难。

正如Robert C.Martin所解释的，这不仅仅是调试：

"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are c***tantly reading old code as part of the effort to write new code . . . [Therefore,] making it easy to read makes it easier to write."

7橡皮鸭调试

这一点与其说是一个原则，不如说是一种技巧，但它是如此的有用和奇怪，以至于我们忽略了它。

首先在实用程序员中讲过，橡皮鸭调试是指通过一行一行地向无生命对象（例如橡皮鸭）解释代码来调试损坏的软件。它之所以有效，是因为解释的行为会触发你大脑的不同部分，你更有可能发现不一致的地方，找出哪里出了错。

因此，无论你是为自己还是为你的编程伙伴买，一只橡皮鸭对程序员来说都是一件非常漂亮的礼物。

8九十九法则

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

汤姆·卡吉尔（tomcargill）的这句厚颜**的小谚语正是为什么编程会如此令人沮丧的核心：无论你认为自己离完成任务有多近，你都比你最好的估计要远得多。当你认为你完成了，你只完成了一半。

它与霍夫施塔特定律密切相关：

"It always takes longer than you expect, even when you take into account Hofstadter's Law."

9帕金森定律

"Work expands so as to fill the time available for its completion."

这一原则由西里尔·诺斯科特·帕金森（Cyril Northcote Parkinson）首创，是一个更广泛的原则，它绝对适用于编程，并与上面的90条规则齐头并进：完成一个项目所需的时间正是它所需的时间。在软件开发中，“提前完成”几乎是一个神话。

帕金森定律是为什么正确的截止日期是至关重要的，如果你想完成并运送你的软件。这就是为什么现代专业程序员经常推荐敏捷项目管理原则和像Asana这样的项目管理工具。

10布鲁克定律

"Adding manpower to a late software project makes it later."

下一次当你在一个项目上迟到的时候，这可能是因为大多数编程项目需要的时间比分配的要多，记住添加编码器并不能更快地解决这个问题。

事实上，这可能需要更长的时间才能完成。你不仅需要使新的编码器（s）的速度，他们很可能会与现有的编码器冲突。更多的事情需要记录在案，更多的****需要让每个人都站在同一个页面上，更多的摩擦会从整个危机时期的经历中产生。

作为一名程序员继续前进

既然您了解了这些原则，您实际上更适合于编程的真实世界，而不仅仅是在学校、网络课程或训练营中遇到的。这些原则来自多年的经验和失败。

有了这个新发现的智慧，你现在可以开始一个更现实的期望高需求编程生涯。为此，学习如何最大化你的编程职业机会。如果你认为编程不适合你，不要担心——考虑一下这些非编码技术工作。

你觉得这些原则中哪一条最正确？你知道我们遗漏了什么奇怪的编程原则吗？请在下面的评论中告诉我们！