您从未听说过的最奇怪的编程原则

我们已经向您介绍了您需要了解的最基本的编程原理，但是还有另一类编程原理可能证明比它们更有益。

虽然上述原则教您如何对代码进行聪明，但是以下原则将教您对代码进行明智。其中有些很奇怪，许多很幽默，但它们都是实用且重要的。注意！

1。膨胀原则

此原则有很多变化，很难选择其中一项作为主要原则。也许最“官方"的版本是软件包络法则，通常更称为 Zawinski法则，以Jamie Zawinski的名字命名，并在 UNIX编程的艺术中提到：

“每个程序都会尝试扩展，直到可以读取邮件为止。那些无法扩展的程序将被那些可以扩展的程序替代。"

这是指随着时间的流逝，程序会吸引越来越多的功能，而不可避免地会逐渐增加其复杂性。您可能将其称为功能爬取，这是不断添加的新功能，这些新功能与程序的主要目的无关。特征蠕变会导致膨胀，并且膨胀通常是不可取的。

这也可以应用于软件性能：

“软件扩展以消耗所有可用资源。"

上世纪90年代，硬盘驱动器，CPU和RAM的限制远比今天严格，程序员努力工作以尽可能地适应极限。但是，现在我们有了更大的驱动器，更快的CPU和更多的RAM，我们仍然很难遵守极限。随着时间的推移，一切都会变得肿。保持检查状态是您的工作。

2。 “越差越好"的心态

几乎是为了回应膨胀原则，我们有越差越好的心态，这是理查德·P·加布里埃尔在他的论文中首次提出的撰写有关软件质量的文章：

“有限但易于使用的软件可能比相反的更具吸引力，对用户和市场更具吸引力。"

In other words, it’s wise to figure out the one problem your software aims to solve and then be very good at that one thing. Keep it simple. The more you spread yourself thin, the more unmanageable the project will become, and the more undesirable it becomes for users.

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

：“一个过于复杂的项目最终将变得过于复杂，甚至连其自己的开发人员也无法理解。"

它来自更广泛的彼得原则，该原则指出，如果根据当前的能力而非下一个职位的预期能力来晋升员工，则所有员工最终都会处于无能的位置。遵循该原则并将其应用于软件，您将了解为什么较差的软件通常可以变得更好。

3。伊格森定律

“您六个月或六个月以上都没有看过的自己的代码也可能是其他人编写的。"

这看似无用的说法是实际上是要拥抱的东西。事实是，没有人是完美的。您可能会认为自己现在是一个天才程序员，但是总是可以学到更多，总是有更多的成长空间。如果您回顾过去的代码并畏缩，那可能意味着自那以后您已经学到了新的东西。

换句话说：如果您回顾一个旧项目并您看不到任何可以改进的地方，或者下次可能会做不同的事情，那么您可能会停滞不前成为程序员。

4。最小惊讶原则

“如果必要的功能具有很高的惊讶因素，则可能有必要重新设计该功能。"

首次发表在《 IBM Systems Journal》 < / em>早在1984年，这一原则在今天仍然令人惊讶地适用-也许比以往任何时候都重要。

它实质上触及了创新与熟悉之间的微妙平衡：如果某软件是与同类产品差异太大并且不符合用户的期望，那么他们很可能不会采用。最好争取渐进式的改进，这些改进要足够大，足以令人印象深刻，但又要足够小以保持熟悉。

5。控制论昆虫学定律

“总会有一个错误。"

通常被称为卢巴尔斯基的控制论昆虫学定律，目前尚不清楚该卢巴尔斯基实际上是谁。但是，他的原则对所有程序员都是正确的：无论您编写代码的方式多么干净，测试模块的功能多么坚固，无论您重构类的频率如何，总会有另一个错误。

在某种程度上，这是一种释放原则。尽管我们绝对应该为没有错误的代码力求，但是记住完美主义是善良的敌人也很重要。查找错误，在出现错误时进行修复，然后继续进行。

6。克尼根定律

“调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，就定义而言，您就不够聪明，无法对其进行调试。"

Brian Kernighan，是共同编写C编程语言的人，以这种有见地的法律而闻名。症结所在是：写好代码，写可读代码，写简单代码，只要不是聪明代码。

尝试利用象牙塔复杂性来增强编程能力与之完全相反这意味着编写干净更好的代码。您的代码越难理解，在不可避免地破坏代码时就越难以调试。

正如罗伯特·C·马丁（Robert C. Martin）解释的那样，这也不只是调试：

"确实，阅读与写作所花费的时间之比远超过10：1。作为编写新代码的一部分，我们一直在阅读旧代码。 。 。 [因此，]使其易于阅读使其易于书写。

7。橡皮鸭调试

这不是一项原理，而是一项技术，但是它非常有用而且很奇怪，我们被遗漏了。

First told in The Pragmatic Programmer, rubber duck debugging is when you debug broken software by explaining your code to an inanimate object (e.g. a rubber duck) one line at a time. It works because the act of explanation triggers different parts of your brain, and you’re more likely to spot inconsistencies and figure out where you went wrong.

因此，无论是为自己购买还是为自己的编程伙伴购买，橡皮鸭对于程序员来说都是令人惊讶的精美礼物。

8。九十规则

“前90％的代码占开发时间的前90％。剩下的10％的代码占了开发时间的90％。"

汤姆·卡吉尔（Tom Cargill）的这个厚脸皮的小谚语是为什么编程如此令人沮丧的核心：无论您有多亲密认为自己即将完成，甚至比您的最佳估计还要遥远。当您认为自己已经完成时，您就只在其中途。

它与霍夫施塔特定律并驾齐驱：

“即使花费了很长时间，它总是比您期望的时间更长请考虑霍夫施塔特定律。"

9。帕金森定律

“工作不断扩展，以填补完成任务所需的时间。"

这一原理由西里尔·诺斯科特·帕金森（Cyril Northcote Parkinson）提出，是一项更广泛的原理，绝对适用于编程并与上述“九十条规则"并驾齐驱：完成一个项目所需的时间恰好是它要花多长时间。在软件开发中，“尽早完成"几乎是一个神话。

帕金森定律是为什么要完成和交付软件的最后期限至关重要的原因。因此，现代专业程序员经常推荐敏捷项目管理原则。

10。布鲁克定律

“在较晚的软件项目中增加人力会使它变得更晚。"

下次您迟到项目时，这很可能是因为大多数编程项目都需要更多时间比分配的要多，请记住添加编码器并不能更快地解决它。

实际上，可能需要更长的时间才能完成。您不仅需要加快新编码器的速度，而且还可能会与现有编码器发生冲突。需要记录更多的东西，需要更多的官僚作风，以使每个人都在同一页面上，并且在整个关键工作时间的经验中将产生更多的摩擦。

以程序员的身份前进

现在您已经了解了这些原理，实际上，您不仅更适合在学校，网络课程或训练营中遇到的知识，而且更适合于现实世界的编程。 。这些原则源于多年的经验和失败。

借助这种新发现的知识，您现在可以着手进行高要求的编程职业。