我們已經向您介紹了您需要了解的最基本的編程原則，但是還有另一類編程原則可能比這些原則更有用。

上面提到的原則教你如何聰明地使用代碼，下面的原則將教你明智地使用代碼。其中有些是奇怪的，許多是幽默的，但他們都同樣實用和重要。小心點！

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）的速度，他們很可能會與現有的編碼器衝突。更多的事情需要記錄在案，更多的****需要讓每個人都站在同一個頁面上，更多的摩擦會從整個危機時期的經歷中產生。

作為一名程序員繼續前進

既然您瞭解了這些原則，您實際上更適合於編程的真實世界，而不僅僅是在學校、網絡課程或訓練營中遇到的。這些原則來自多年的經驗和失敗。

有了這個新發現的智慧，你現在可以開始一個更現實的期望高需求編程生涯。為此，學習如何最大化你的編程職業機會。如果你認為編程不適合你，不要擔心——考慮一下這些非編碼技術工作。

你覺得這些原則中哪一條最正確？你知道我們遺漏了什麼奇怪的編程原則嗎？請在下面的評論中告訴我們！