前言：“扒一扒你遇到過最NB的開發專案”，看到CSDN上舉行這個活動，就迫不及待的趕緊點進去看看到底是什麼玩意er，一不小心看到了《人月神話》的試讀活動，內心有兩個聲音就悄悄鑽了出來：一個有點怨言，一個有點激動。所謂怨言，就是活動姍姍來遲，如果《人月神話》能夠早一點讓我一睹芳容，而不是在苦苦尋找後相見恨晚該多好；所謂激動，自然是“終於等到你，還好我沒錯過”（好像詞有點跑偏）。

溫故而知新

其實在CSND舉行這個活動之前，我已經認識了《人月神話》，那是在看Jeff的《高效能程式設計師修煉之道》一書後，強烈的感受到，作為一個程式設計師，我竟如此的孤陋寡聞，Jeff推薦的必讀書籍列表，我一本都沒有讀過。深深地自責後，我從京東上買下了《人月神話》和《軟體方法上冊》。對於《人月神話》，我的札記已經寫到了“

“我所收集的書中，軟體工程書大都屬於精品，神品只有兩本，Brooks的這本就屬於神品之列”。我對“Dave wang”的代序之言由衷的表示贊成，所謂“書讀百遍其義自見”，有幸再次拜讀Brooks的書籍，我深感自豪。

程式設計師的苦與樂

我自認為，程式設計師很“悶騷”，當然我自己就是一個程式設計師，哈哈。不過我認為悶騷的含義應該是這樣的：
悶，代表我們很單純，我們通過程式設計，不斷地解決使用者的痛點，我們深陷於這種快樂而無法自拔，我們不願意花費精力在其他方面，唯有程式設計；騷，代表我們富有活力，一旦有事情激起我們的興趣，我們為之亢奮，不惜暴露我們的激情。

程式設計，Brooks稱之為焦油坑，這個讓我們苦苦掙扎，卻又充斥著苦惱，但又充滿著快樂的創造性活動。作為程式設計師，我們愛之深，責之切，我們經常抱怨加班、需求變更、外行的無厘頭要求，但是我們享受軟體釋出後的快樂，我們享受程式設計過程中的美好時光，我們享受使用者使用後的讚美。

那麼快樂來自於什麼呢？

1. 創造事物的純粹快樂
2. 開發對他人有用的東西

而那些苦惱又從何而來呢？

1. 追求完美
2. 他人設定目標、提供資源
3. 專案完工了，她也該香消玉碎了

人月徒傷悲

在國內，有這樣一群領導：
- 他們要求產品應該在一個月、兩個月、半年內完成；
- 他們認為專案進度一旦拖延，立即增加人手就可以馬上解決問題；
- 開發能遇到什麼問題，產品優良他們並不看重，他們只在乎利益。
- ……

顯然，我們的領導迷信了人月的“神話”，對於這樣的神話，Brooks在書中論證了為什麼“Adding manpower to a late software project makes it later”，也就是說向進度落後的專案中增加人手，只會使進度更加落後。

Brooks舉了兩種型別的例子：
1. 無論對於哪一個母親，孕育一個孩子都需要10個月。
2. 割麥子的時候，人手多一些，顯然麥收會提早完成。

對於軟體開發領域的我們來說，人月徒傷悲的原因有哪一些呢？
- 開發團隊需要溝通，很少有專案是一個人來完成的，即使只有一個開發人員，也免不了和外界溝通，況且孤獨的開發者需要被鄙視，閉門造車會讓專案更容易失敗。
- 開發團隊的成員能力並不能確保完全同級，如果相互差距比較大的時候，溝通的成本就會越高。所謂木桶理論就是一個證明，決定木桶盛水的容量是由高度最低的那塊木板決定。

讓神話離我們遠去

我從一篇人月神話的讀者感言中瞭解到，為了能夠主動出擊，我們可以做一些改變：
1. 不再低估每一個產品的難度，保持警惕而不是“樂觀”會讓我們更從容。也就是說，在計劃每一個任務的時候，盡你所能，保持客觀冷靜。
2. 提前多幹一些。進度表上的時間與實際開發中的時間不可能步調一致，那麼很多人容易這樣想，反正今天的任務已經完成了，就算是有空閒時間，我也不再繼續了；更糟糕的是，今天的任務雖然沒有解決，但是明天的任務好像挺簡單的，今天就結束吧，明天再繼續。請拋棄這種可怕的想法吧，儘量提前多幹一些！！！
3. 在領導施壓下，請盡力堅持自己的進度安排。Brooks也說了：“在顧客的催促下，廚師選擇把火加大，不過結果常常是無法挽救的煎蛋—-一面已經焦了，而另一面還是生的”。

從華夏三方存管平臺對接中總結經驗

我們的“期貨交易平臺”要對接華夏的三方存管平臺，任務從今年4月份已經開始了，我曾經這樣和客戶講：“如果一切順利的話，我只需要一天半的時間就能對接完”。現在回想起來，我自己都情不自禁的笑了，我是有多欠！時至今日，兩個月就要過去了，正式環境上的介面對接還遲遲沒有疏通完成。

首先，樂觀主義害死人。說樂觀都有點牽強人意，我當時完全是一種盲目自大，當然我還給自己留了一點點餘地，“如果一切順利的話”。但是，現在回想起來，正應了Brooks那句話“他們所犯的第一個錯誤是假設一切都會進行得很順利”

其次，“程式設計人員很少能控制工作環境和工作目標”，這兩個月的工作讓我深有體會，依賴別人，太過痛苦。

在對接華夏介面的兩個月內，先是CFCA的keystore斷斷續續阻礙了三個星期的時間；

再者是華夏銀行的阻力：
1. 現在都2015年了，華夏提供的介面文件竟然是2011年做成的，最後我們要了一份2014年改版的。
2. 華夏提供的jar包有嚴重bug，他們的getter、setter方法有的是大寫，有的是小寫，導致轉換json字串時出現問題，最後只能是採用迂迴戰術解決。
3. 分行的對接人員垃圾的一塌糊塗，你還必須強顏歡笑，他們對業務的熟練程度還不如我。
4. 總行的一些人員推脫責任，早上說下午就可以了，下午說明天就可以了，尼瑪明天是星期六，他們不上班！
5. 華夏內部的稽核機制有太多NM，這個就不能太多透漏了。

再者，輕視測試。在完成程式碼編寫後，沒有程式碼評審、沒有單元測試、系統測試也不夠全面，這就會滋生很多顯而易見的bug，不過值得慶幸的是，我在正式上線前解決了這些問題。

完美與放棄

我個人在生活和工作中都有點追求完美，這一點在工作中表現的尤為突出：
我受夠了那些垃圾程式碼，從2014年2月接收專案，到如今，我對程式碼進行了不計其數的重構，舉個例子，我們使用的一個web管理系統最開始打完war包足足有48M，而現在只有17M，當然這還有點多。

而對於一些功能，我會選擇放棄，尤其是對於客戶那些”無理取鬧“的需求，我會通過各種手段讓他放棄自己的想法。

Brooks說了：”實際上，我認為，學習程式設計最困難的部分，是將做事的方式向追求完美的方向調整“，好吧，看到這點，我有點沾沾自喜了。

總結：《人員神話》不愧是一本”神品“，前兩個章節，我已經讀了不下十遍了，但每次都完，都覺得如沐春風，哈哈！最後，來看看文言版的”人月神話“：

問：今有程式設計師五人，需時日幾何？
答曰：一年。
問：吾急需之！若有十人，幾何？
答曰：兩年。
問：百人若何？
答：萬世。