柯林漢定律 (Kernighan's Law)

Brian Kernighan 在其著作 "The Elements of Programming Style" 提出一個經驗法則，稱為 Kernighan's Law。

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 smart enough to debug it.

除錯要比寫程式困難兩倍，
因此，如果程式寫得很精巧，
那你就沒有足夠的智慧能夠除錯。

對這句話的理解，我認為是跟程式的簡潔度及可讀性有關。

越複雜冗長的程式碼，因為程式碼太長，在 debug 時，就越不容易找到問題點。但有些人會在寫程式時，追求到極致，希望能用非常短的程式碼完成。One-liner program 的目標是，用一行程式碼完成一項功能，追求簡潔的程式碼。

這種做法沒有對錯，在高階程式語言，用很短的程式碼完成很多事情，比較容易發生，但在中低階語言，像是 C 語言，刻意追求 one-liner，會產生反效果，因為程式碼太短，而讓人難以理解在寫什麼。

因此良好的程式，應該要具有相當程度的可讀性，可讀性並不代表程式碼很多或很少，而是程式碼以大家都能理解的方式撰寫，程式的結構良好，一個可讀性高的程式，程式碼的長度可長可短。

原文中的精巧，可能是針對 C 語言的說法，因為 C 語言是中低階程式語言，精巧的程式，是聰明的寫法，也代表能用比較短的程式完成工作，在 CPU 及記憶體貧乏的時代，這種做法是有必要的，但這也代表這些程式碼會讓人難以理解，也就更難除錯。

Brian Kernighan 跟 Dennis Ritchie 是 "The C Programming Language" 這本經典書籍的作者，這本書是所有寫 C 語言要閱讀的經典書籍，也因為這本書，建立了一個規則，所有程式語言的第一個測試程式，都是要列印 "Hello, World!" 這個字串到螢幕上。另外這本書的 C 語言 coding style 也被稱為 K & R style。

Kernighan 還是 Unix 作業系統的命名者，原本被稱為 UNICS (Uniplexed Information and Computing System)，另外還是 awk 這個工具的作者。

References

80歲了還在改程式碼的大神：他是Unix命名人、寫下所有程式新手的「Hello World」起手式 | T客邦

過早優化效應 (Premature Optimization Effect)

Donald Knuth 在 The Art of Computer Programming 提出了過早優化法則

We should forget about small efficiencies,
say about 97% of the time:
premature optimization is the root fo all evel.
Yet we should not pass up our opportunities
in that critical 3%.

有 97% 的優化是不值得花時間去做的，過早優化是萬惡根源。
但還是要注意在關鍵的 3% 要提早去優化。

把開發時間花在不重要的優化上，可能會因為過度優化，而化簡為繁，讓系統太過複雜。過早的優化，會浪費大量資源，包含時間、金錢、人力，同時也可能因為這些優化，而衍生出其他的問題。

對於這個法則的爭論點在於，系統的哪個部分是關鍵的 3%。

這個問題跟開發人員的經驗、能力，專案的時程跟預算，系統規劃時設定的最大容量這些有關係。

要知道系統的 3% 關鍵，需要在產品規劃與設計時，就能夠預判系統的使用環境，同時的上線人數。但要能正確預判專案的基本條件並不容易，尤其是一個面對未知系統人數的服務，因為我們永遠不知道，這個系統是不是會爆紅而導致系統的瞬間流量突然增加。一但發生這個狀況，也只能面對，因為一般使用者，甚至是系統的 stake holder 都無法正確預判，有時候就只能等到事情發生了才知道，但也過了那個大流量的使用時機，因為使用者已經失去了信心，不會再用。

有經驗的開發人員，因為經驗的累積，能夠用以往的專案經驗，在新專案一開始的時候，就套用了一個基本能夠彈性修改的系統架構，但難免會遇到一個根本的問題，就是系統的運作硬體環境，程式語言或是 framework 本身的性能瓶頸，或是專案預算的限制。

問題都是存在的，但我們要知道，所有的系統使用時都有極限與限制，盡可能以漸進的方式使用某項新的系統與技術，用保守的態度面對，這樣應該比較能避免遇到問題。激進的方法當然也有可能成功，就看後續的問題處理，運氣好的話，也能撐過動蕩期。

References

过早优化是万恶之源——克努特优化原则 (Knuth's optimization principle) - 腾讯云开发者社区-腾讯云

# 流言終結者：過早進行優化是萬惡之源？

# 「过早的优化是万恶之源」这种说法对不对，为什么？

帕金森瑣碎定理 (The Law of Triviality)

Cyril Northcote Parkinson 於 1957年提出，大型組織會花費大量時間在無關禁藥的瑣事上，但是遇到重大議題時，卻能很輕易地通過。這是因為一般人對於重大議題，無法完全理解而怕貿然提出建議而失言。對於一般簡單瑣碎的事情，因為基本認知足夠，故會有很多意見，造成大型組織在事項的討論度，花費的時間與其重要性成反比。

Parkinson 在 Parkinson's law, and other studies in administration 這本書中提出了幾個實例：

1. 1000萬美元的核子反應爐，審查委員中有四個不知道反應爐是什麼，三個不知道有什麼用，兩個不知道預算多少，剩下的其中有兩個對預算有疑慮，一個提出要找專家，一個覺得無法講清楚，所以就不表示意見，整個議題花了2.5mins 通過。

2. 建自行車棚，大家的意見很多，爭論要用什麼材料跟預算多少才合理，花了很多時間大家聽懂了，討論了 45mins，節省 300 美元。

3. 飲料要選什麼？他們花了很多時間討論，有些人覺得不要花時間討論，但有些人爭論要不要提供咖啡，最終他們要求秘書弄清楚每個人的需求再決定。

瑣碎定理是對議題的討論狀況的描述，大部分都會是在一個會議中會發生，要避免發生瑣碎定理的問題，有幾個方法

1. 事先準備

   提前告知與會人員會議的議題，大家能預先了解議題內容，才能快速針對議題進行討論。臨時告知的議題，多數人會覺得是意外，沒有先備知識，就無法提出適當的意見進行討論。

   事先對於會議定下規則，限制每個人的發言時間，或是要求大家都要發言。

2. 預先安排議程

   一般傾向把最重要的事情留到最後再說，但應該把最重要的議題放在最前面討論，要能面對並解決問題，最好的方法就是開門見山

3. 盡可能減少或不開會

   減少沒有用的會議，訊息傳遞在現今的科技下，已經不是問題。並不是所有的資訊，對每個人來說都是必要要知道的。

References

帕金森瑣碎定理 - 維基百科，自由的百科全書

帕金森瑣碎定理 - MBA智库百科

經濟學人：如何避免出現「帕金森瑣碎定律」 - 每日頭條