前言

這本是在 PyCon TW 2016 天瓏書局擺攤時買的（六月初），
一直到七月中才開始看，
八月初才看完，
看的速度好像真的有點慢 Orz
然後又拖了一個月，
才生出這篇文章。
（究竟什麼時候才能脫離拖延症患者呢？）

其實網路上要下載這本的電子書隨便找都找得到，
我自己也有一本，
但後來發現自己還是比較喜歡看實體書的感覺，
電子書就當作收藏吧！

二十週年紀念版新增了以下幾個章節：

• 第 16 章 — 沒有銀彈：軟體工程的本質性與附屬性工作
• 第 17 章 — 再論「沒有銀彈」
• 第 18 章 — 《人月神話》的主張：是真是假？
• 第 19 章 — 《人月神話》二十年

讀完以後我覺得這四個新增的章節都蠻重要的，
畢竟有作者自己的反思以及一些讀者的回饋，
非常值得邊讀邊思考，
我想以後再工作更長一段時間甚至是擔任管理職以後，
可能會對書中說的事情更有體會吧。

作者簡介

Frederick Phillips Brooks, Jr.

• 曾在 IBM 管理過非常大型的 OS/360 系列專案，本書就是他集結這些大型專案的開發經驗後得到的結論並分享出來。
• 1999 年圖靈獎得主。

紀錄

以下附上我自己讀的時候把比較喜歡的內容拍下來的照片：

• 
  • 公車上拍的... 窗簾有點紅...
• 
  • 這個比較圖不知道會不會引起戰爭
• 
  • 尤其是一堆公司會讓很會寫程式的人去當管理者
• 
  • 覺得沒有幾間公司可以完全做到以上這幾點，而且中間還有很多變因，但真的是很理想的情況啊。
• 
  • 我也覺得流程圖真的蠻雞肋的，但即便是到了現在，好像也沒有出現什麼更好的將程式視覺化的方法？頂多就是讓流程圖變成用程式產生，但這邊的流程圖是要在程式設計之前就要事先畫好的東西，類似設計圖的概念，讓人可以提早檢驗出設計上的缺失。也許就像本書自己講的，軟體工程上的本質不同，所以要像這樣採用和其他工程學一樣預先畫出設計圖的方法可能也不太可行？而且實務上的經驗來說，頂多只能概略的畫出架構圖，但這是針對伺服器的架構，好像很少人在寫一個程式之前會先畫出流程圖的。
  • 即便是採用 Extreme Programming，把程式拆成好幾個部份，不要一次設計全部。我覺得還是得需要先設計出一個約略的架構，否則到最後應該還是會有拼不起來的問題？
• 
  • 即便已經證實有更有效的方法，人類也很難在短時間內就讓自己改變已經習慣的方法。
  • 看看特別用來設計讓人打字變慢的 QWERTY 鍵盤還是遠遠多餘特別設計用來讓人打字變快的 Dvorak 鍵盤就知道了？

特別喜歡第 16 章：《沒有銀彈》，
點出了很多軟體開發中本質上的瓶頸。
其實跟社會上所有的問題一樣，
改變最慢的永遠是人類。
我想這也是這本書可以暢銷這麼久的原因吧？
科技進步的速度飛快，
但人類的思考方式與軟體開發的方式其實並無太大幅度的成長。
而軟體工程又與其他工程有著不小的差異，
例如建築工程，增加搬運工人、水泥車等等，
基本上可以讓建築速度獲得提升。
但對於軟體工程來說，
對一個已經開始開發的專案，
加入新的軟體工程師，
基本上只會讓進度更加落後。
（這也是本書的同名章節《人月神話》所表達的核心觀念）

但軟體又不能慢慢開發，
房子蓋了很久才蓋好仍然可以住人，
但軟體開發很久才開發完的話，
等開發出來以後早就過時而且沒人要用了。

然後印象中，
《焦油坑》那個章節也滿不錯的。
（請原諒一個過了一個月才回想讀書內容的人QQ）

真的是個值得多閱讀幾次的好書，
我覺得不管是專案管理者還是軟體開發者真的都推薦看一下。

軟體開發真的還有很多本質上的難題懸而未解，
後面新的章節也有列出作者認為一旦被解決了，
就會讓軟體開發有質的躍進的那些問題。

References

• The Mythical Man-Month - Wikipedia, the free encyclopedia
• Fred Brooks - Wikipedia, the free encyclopedia