布魯克斯法則 (Brooks's Law) - 人月神話

Frederick P. Brooks, Jr. 於 IBM System/360 開發階段任職專案經理，OS/360設計階段任職軟體專案經理。在他管理的軟體專案經驗中，他將經歷寫成一本著名的軟體開發管理書本，名為「人月神話」。

在人月神話中，他提出一個觀念：在一個進度已經落後的專案再增加人手時，只會讓這個專案進度拖延更久。

在軟體專案管理中，有一些重要的事項，就是開發人力跟耗費的時間。這些估算工作，很多時候只能用經驗法則來判斷，由於這個估算無法非常準確，而且會隨著時間的前進，一直不斷地變化。

多數的管理人員都會用很單純的人月互換法則，來進行工作的估算，例如一個 10 人月的工作量，要直接分配給 5 個人用 2 個月的時間開發。

這是因為工作項目在切割的同時，就發生了項目的先後關係，且每一個項目在不同人員開發時，得到的成果跟品質不同，最後也會在整合階段，發生不同的問題，導致實際上不可能發生 10 人月 = 5 人 x 2 月。

一般在遇到進度延遲的狀況時，第一個反應會是增加人手，就像是蓋房子蓋到一半趕進度，就會想要從別的地方調派人力過來幫忙。但軟體專案沒有辦法依照這種想法處理，任意增加人手，很有可能會讓專案問題更亂更複雜。

造成這種現象的原因可能有：

1. 專業工作無法任意切割

2. 溝通成本大幅增加

3. 新人無法快速融入團隊開發

4. 舊人要暫停工作，做新人的教育訓練，需要更多時間，這些時間無法反映到實際的專案進度上

最明顯的實例，就是一個女人生小孩需要耗費 10 個月的時間，但十個女人生小孩，一樣需要 10 個月，因為這是一項專業工作，無法任意切割。

References

布魯克斯法則 - MBA智库百科

又delay了...為什麼人手增加後，專案進度反而死更慘? - Project Club 專案管理輕鬆學

專案管理你要知道事情 布魯克斯法則 ( Brook’s Law ) | lalacube

浅谈软件开发定律系列之布鲁克斯定律_柳记的技术博客_51CTO博客

阿姆達爾定律 Amdahl's Law

Amdahl's Law 是 1967 年 Amdahl 發表的論文提出的法則。

當時的命題是，在平行運算的研究領域中，一個程式可以分為可被平行運算與不能被平行運算兩個部分，當我們針對平行運算做效能提升的研究時，應該把時間跟經費做最有效率的投資，但究竟平行運算可以帶來多少效益？

\[ T = 程式以序列運算的總時間 \\ B = 程式中，無法被平行化運算的部分的運算時間 \\ T-B = 可被平行化運算的總時間 \\ N = number of Threads/CPUs \\ T = B + (T-B) \\ (T-B) 部分可被平行化，變成耗費時間 (T-B)/N \]

假設 T 為 1

\[ \text{if N=2} => T(N) = B + (T-B)/2 \\ \text{if N=3} => T(N) = B + (T-B)/3 \]

可得到程式運算的總時間

\[ T(N) = B + (T-B)/N \]

假設 T = 1, 只能序列運算的部分 B = 0.5, N = 2

\[ T(2) = 0.5 + (1-0.5)/2 \\ = 0.5+0.5/2 \\ = 0.75 \]

當 Thread/CPU 越多，就代表程式運算的總時間會減少。

---

另外有一個程式加速的指標參數

\[ Speedup = \frac{Original Execution Time}{Execution Time After Enhancement} \\ = \frac{1}{B+(1-B)/N} \]

如果程式有一半的部分可被平行化加速

\[ N=2, Speedup = \frac{1}{0.5+(1-0.5)/2} = 1.33 \\ N=4, Speedup = 1.6 \\ N=100, Speedup = 1.98 \\ N=1000, Speedup = 1.998 \\ N=10000, Speedup = 1.99998 \\ N=\infty, Speedup = 2 \]

意思就是，就算平行化運算可以無限的加強效能，減少運算時間，程式的總運算時間，會被無法平行化運算加速的部分限制住。

如果有兩件事，我們不知道應該去做哪一項時，也可以利用這個法則決定，取效益比較高的那一個。例如：讀書時不知道要先讀數學還是英文，先假設數學是無法提升的部分，算出 Speedup，再用英文為B，算出 Speedup，兩個互相比較，就可以知道哪一個效益較高。

但真實世界也不是那麼簡單的事，因為我們無法預先知道，最佳化後的成果，是不是跟預先假設的成果效益一樣。另外以讀書為例，我們也不知道一直都看不懂的英文，要花多少時間，才能改進並得到效益，反而是比較熟悉的數學還有進步空間，因為看不懂的東西，再怎麼看也不懂，就算看懂以後的效益很高也沒有用。

References

OpenMP: Amdahl's Law - YouTube

阿姆達爾定律 - 維基百科，自由的百科全書

Day27：阿姆達爾定律（Amdahl's law）——資源配置的哲學 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

Amdahl's Law · 課程筆記

阿姆达尔定律(Amdahl’s Law) 计算51CTO博客amdahl 定律

tcpkill

當 TCP 已經建立連線後，使用者可在此連線下，持續傳送封包資料，這時候加上 firewall rule 擋掉該來源 IP 無法作用到已經建立的 TCP 連線上。在不停掉提供服務的 server 的狀況下，可以透過 tcpkill 強制關閉該 TCP 連線。

tcpkill 在 dsniff 套件中，在 CentOS 可透過 epel repo 安裝

yum -y install dsniff -enablerepo=epel

tcpkill 切斷 TCP 連線的原理是，模擬發送 RST 封包，但因為發送該封包必須要先知道 SEQ/ACK，所以執行 tcpkill 會發現程式並沒有馬上結束，而是持續在 listening 的狀態。

這時候 tcpkill 會持續監控網路封包，直到有收到符合條件的封包時，才能結束該 TCP 連線。

在使用前，可先用 netstat -anlp 查詢目前的所有網路連線 IP 及 Port 狀況。可用 ip host 或是 port 參數指定條件。

# tcpkill ip host 1.2.3.4
tcpkill: listening on eth0 [ip host 1.164.232.236]
1.2.3.4:38784 > 192.168.1.10:5556: R 305630104:305630104(0) win 0
1.2.3.4:38784 > 192.168.1.10:5556: R 305638604:305638604(0) win 0
1.2.3.4:38784 > 192.168.1.10:5556: R 305655604:305655604(0) win 0
192.168.1.10:5556 > 1.2.3.4:38784: R 2839752684:2839752684(0) win 0
192.168.1.10:5556 > 1.2.3.4:38784: R 2839754086:2839754086(0) win 0
192.168.1.10:5556 > 1.2.3.4:38784: R 2839756890:2839756890(0) win 0
^C

再利用 netstat 檢查 tcp 連線後，就可確認沒有來自該來源 IP 的 TCP 連線，後續因為設定了 firewall rule，確實擋掉了該 IP，也無法建立新的連線。

心理防衛機制 Defense Mechanism

心理防衛機制是人類的正常反應，人類在無意識中，透過心理防衛機制，減輕不能接受或可能有害的焦慮。

一個人會產生的防衛機制，跟心智成熟度有關，越原始的防衛方法，效果越差，維持的時間也會比較短。

原始的防衛機制

Denial 否認

拒絕現實發生的事情，假裝某個想法或事件沒有發生過。

Regression 退化

當承受過多壓力時，行為動作可能會回到嬰幼兒時期，像一個小孩一樣，這樣會比較有安全感

Acting Out 行動化

以極端的方式宣泄情緒，例如丟東西，搥牆壁，甚至是自殘。

Dissociation 解離

一個人失去時間感，或暫時失去人格完整性，例如在車禍後，喪失發生時那一個片段的記憶

Projection 投射

將自己無法接受的想法，賦予到別人身上，推卸責任藉此得到解脫。

Reaction Formation 反向作用

心裡想的跟實際做的完全相反，例如男生會故意捉弄喜歡的女生

稍微成熟一點的防衛機制

Repression 壓抑

遺忘造成心理創傷的事件，就不會被該事件影響

Displacement 替代

將接收到的情緒，轉移到別人身上，特別是身邊親密的人。例如工作上被責備，回家後對家人吼叫

Intellectualization 理智化作用

遇到悲傷的事，或是不如預期的事情，會想出一套說詞說服自己

Rationalization 合理化作用

用看似合理的藉口去解釋某些行為

Undoing 抵消

一個人試圖挽回下意識傷人的行為或話語

成熟的防衛機制

Sublimation 昇華

將心裡面不符合社會規範的衝動或慾望，以合於社會規則的方式表現出來。ex: 自嘲

Compensation 補償

當自己心理或生理有某些缺陷，會發展其他部分彌補這個缺陷

References

心理防衛機制是什麼？你我的潛意識都會保護自己 - Hello 醫師

心理防衛機制 - 維基百科，自由的百科全書

你心智多成熟？看你「心裡防禦機制」就知道！12種防禦機制！【心理學】 | 維思維 - YouTube

Gall’s Law

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and can not be made to work. You have to start over, beginning with a simple system." - John Gall, systems theorist.

一個複雜的系統，是由簡單的系統慢慢演化而來的。如果要從無到有，設計出一個複雜的系統，是絕對不可能成功的，任何複雜的東西，都要從簡單（基本）做起。

一個外表看起來複雜的系統，如果仔細去分析內部的架構，會發現它是由很多簡單的結構組合而成的。沒有一個系統可以無中生有憑空產生。

這是系統分析要做的事情，系統分析就是要透過設計的方法，將一個完整複雜的系統，切割為多個可被容易理解的子系統/流程。但分析不能太過注意細節，系統與流程的實作細節，要交給系統設計去處理。因為一個太精細的系統分析結果，反而會讓人難以整合出整個系統全貌。

跟 Gall’s Law 類似的法則是 KISS Principle。

Keep it simple, stupid (KISS) 就是在進行系統設計時，要盡可能保持簡單。換句話說，就是不能做過度設計 over design，過度設計的系統，會因為多餘的考量，讓使用者難以理解，也會犧牲掉運作的靈活/流暢度。

另外還有一個類似的奧卡姆剃刀原則 Occam's Razor

「切勿浪費較多東西，去做『用較少的東西，同樣可以做好的事情』。」

「如無必要，勿增實體。」(Do not multiply entities beyond necessity.)

這幾個原則都有一些共同的代名詞：化繁為簡、避重趨輕、避繁逐簡、以簡御繁、避虛就實。

References

对开发人员有用的定律、理论、原则和模式 - 腾讯产业互联网学堂

KISS原則 - 維基百科，自由的百科全書

奧坎剃刀 - 維基百科，自由的百科全書