人月神話劄記：未雨綢缪

前言：軟體在設計階段如果能夠多考慮一些後續的維護工作，顯然是非常棒的。然而對于現階段的我，或者很多程式員來說，未雨綢缪有很大難度，我們往往即使已經下雨了，也依然無法把窗戶關緊，那麼如果你想得到一些指導的話，請随我來，看看我能否品出一些味道來。

沒有什麼是永恒的，除了變化。

普遍的做法是，選擇一個方案，試試看；如果失敗了，沒關系，再試試别的。不管怎麼樣，重要的是去嘗試。

我覺得書中提供的這兩個觀點非常的棒，首先，任何事都不可能一成不變，靈活宣言也提倡我們要擁抱變化。其次，在解決問題的時候，就是要不斷的嘗試，這個方案沒有解決問題，就去嘗試另外一個，直到你想不到别的辦法，你再去求救别人。

實驗性工廠和增大規模

現如今，很少有公司敢把沒有經過beta測試的産品直接上線運作，那帶來的後果是不可估量的。

當你完成了代碼測試，就覺得程式萬無一失，着急上線的話，往往打擊是慘痛的。就如同諸葛亮認為馬谡熟讀兵法再加上跟随諸葛亮多年，派他去守街亭，結果被馬谡的昏招教訓的慘痛。

在好不容易開發出第一版産品後，即使它非常的差，我似乎很眷戀它，無法丢棄它。然而更好的做法是，在開發第一版産品的時候，要考慮在日後變更它，甚至丢棄它的可能性，至少能夠對一些關鍵點留下後路。

唯一不變的就是變化本身

我個人就非常的讨厭一個方案确定下來後，再因為使用者的需求變化而做出調整，從思想的源處，我似乎還沒有接受這種觀念，說實話， 我就是厭惡變化。

但是現實就是喜歡開玩笑，使用者的需求會變化，軟體的技術會變化，你的能力會變化，如果你在設計之初沒有考慮到變化，那麼當你不得不做出改變的時候，将會十分的痛苦。

舉個例子來說，銀行流水号，一般情況下，年月日時分秒+4位随機數就夠用了，于是你可能把字段設計為long型，字段長度為18位。如果你這樣做的話，我告訴你，你會後悔的，你最好設計為string類型的25位長度的字段，這樣才能擁抱變化。

為變更計劃系統

的确，變更就想小孩子的臉，如果你不準備好糖果或者奶水，那麼一旦小孩子變臉，你将無法再控制他。那麼對于軟體設計，我們能做些什麼呢？

為産品疊代建立合适的周期和版本。

采用更進階的軟體架構和開源技術。

為變更計劃組織架構

當隻有一個新野的時候，劉歇業沒有選擇的就要駐紮在一起；而當有了徐州和小沛，三人就要分開，但至少有兩人還在一起；然後當有了荊州，并且了雙線進軍西川的時候，三人就要完全分開。而在此時，關羽要做的不僅僅是守荊州，同時還要單刀去赴會；張飛不僅僅要葭萌關大戰馬超，還要能使用計謀義釋嚴顔；彼此在武力和智力上都要經得住考驗。

那麼在應對軟體變更過程中，組織可以做些什麼來應對呢？

技術人員和管理人員具有互換性。（目前的我似乎已經習慣于在更多的角色定位中穿梭）

在管理線和技術線上設定具有相同薪水的不同階層，同時樹立各自的威信。（每朝每代，文官和武館都會站在不同的列隊，然而層級是一緻的，這樣就確定文武百官各司其職，并且能夠互相依賴）

當然最好的就是，每個人都能文武雙全，像周瑜（三國演義是為了襯托出諸葛亮的牛，但事實上周瑜在智力和武力上都屬于頂級水準）一樣，這樣可以使結果在面對變化的時候進行更快捷的調整。

前進兩步，後退一步

對于廣泛使用的程式，維護成本通常是開發成本的40%或更多。

缺陷修複總會以固定（20%-50%）的幾率引入bug。

總體上能夠前進一步，已經實屬難得。結合我自身的經驗就知道，在現實的軟體開發以及維護中，每當修複一個目前問題時，總會有一定幾率引入新的bug，我之前總是怪罪自己的不小心，但是後來我知道，能夠快速解決問題才是王道。即使像諸葛亮也無法預知在他進行七星燈工作的時候，魏延在最後關頭擺了他一刀。

前進一步，後退一步

用在修複原有設計上瑕疵的工作量越來越少，而早期維護活動本身引起的漏洞修複工作越來越多。

這個現象也普遍的發生，有些産品無論再怎麼改進，他的水準也就維持在那樣一個高度，不會發生質變。

那麼最好的方式是什麼呢，那就是重新再來一個。就如同中國的道路一樣，沒過一段時間，就要讓人忍受馬路的修修補補，然而并不能從根本上解決問題，一段時間過後，另外一處要重新打上更新檔。那麼如何解決呢，那就是放棄那個豆腐渣的公路吧，重新搭建一條新馬路。