2023/8/21

柯林漢定律 (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客邦

2023/8/14

過早優化效應 (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) - 腾讯云开发者社区-腾讯云

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

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

2023/8/7

帕金森瑣碎定理 (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智库百科

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

2023/7/31

帕金森定理 (Parkinson's Law)

1955年 Cyril Northcote Parkinson 在 The Economist 發表一篇短文

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

在工作能夠完成的時限內,工作量會一直增加,直到所有可用時間都被填充為止

後來在 1958年,擴充為一本書:Parkinson's Law: The Pursuit of Progress

The demand upon a resource tends to expand to match the supply of the resource (If the price is zero).

在預算之內,支出的需求會一直增加,直到所有資源被用完為止

員工會製造很多瑣碎的工作,讓自己看起來很忙,就算時間充裕,也會放慢工作速度,或是找其他的事情做,直到預定的交付時間被填滿。後續又以工作量增加要求招僱更多員工,組織漸漸膨脹,但從外面看起來,大家看起來很忙,實際上是工作效率低下。

  1. 增加下屬法則

  2. 增加工作法則

為避免工作拖延的狀況,管理者可以安排更多工作,或是制定不合理的交付時間。但這樣的作法可能會有副作用:

  1. 期限內無法完成的事情會越來越多

  2. 為了在期限內完成,無法確保工作品質

  3. 員工因不堪負荷而離職

本定律要發生有四個條件

  1. 要有一個組織,管理階層在組織中佔有一定的地位

  2. 該管理者能力平庸,是個不稱職的管理者

  3. 對該管理者而言,可能因為某些事情而喪失權力

  4. 該組織是個不斷自我要求完善的組織,能夠不斷吸收新人

References

帕金森定理 - 維基百科,自由的百科全書

# 帕金森定律》為何公司的人越來越多,生產效率卻越來越差?

帕金森定律:如何克服它以提高生產力 • Asana

《每個人的商學院・管理基礎》:大企業最常犯的「帕金森定律」與「彼得原理」 - The News Lens 關鍵評論網

帕金森定律 - MBA智库百科

2023/7/24

隱式接口法則 (Hyrum's Law, The Law of Implicit Interfaces)

在 Google 開發 C++ library 的工程師 Hyrum Wright 在網站 https://www.hyrumslaw.com 提出一個軟體工程中觀察的經驗法則:

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

當某個 API 有了相當多的使用者以後,
原本的規格已經不重要了:
因為所有可被發現的系統行為,
都會被某人使用,並依賴該系統行為。

API 是系統模組之間互相交互運作的介面,也是某個功能模組的抽象化,因為單一功能模組的內容細節過於複雜,無法讓所有人都理解細節,故使用者會透過抽象介面使用該功能。

隨著系統的使用者增加,會漸漸地透過實作的細節,慢慢披露出該模組的未公開的功能內容,導致有越來越多的使用者,依賴於該 API 的所有系統行為。也就是隱式接口法則。

隱式接口通常是慢慢發生的,使用者並不會意識到正在發生,例如:API 通常沒有性能保證,但使用者會期待該 API 能夠達到某個程度的運算能力,這表示 API 可能需要被慢慢修改到符合使用者的期待。

例如 Hash 的輸出順序,在原本的定義中,並不會保證有固定輸出的順序,但某些語言實作時,會發生固定輸出順序的狀況,導致有使用者套用這個規則使用 Hash。

References

海拉姆定律——一个软件工程的观察

软件工程中的海仑定律 - hyrumslaw

程序员应知必会的思维模型之 16 隐式接口定律 (Hyrum‘s Law or The Law of Implicit Interfaces)_知识大胖的博客-CSDN博客_hyrum's law