洼則盈 關注軟件開發中的過程、架構、人……

1，不要完全依賴人來測試我們的代碼——用代碼來測試我們的代碼。 　　2，不要完全依賴人來驗證我們系統的集成——用自動化腳本，用持續集成軟件。 　　3，不要依賴人工一次性的勞動來確保軟件的正確——用分而治之、迭代開發來“反復確保”。 　　4，不要等軟件腐化后再來“重寫”軟件——時時刻刻“重構”它。 　　5，不要期待設計/架構可以一步到位——時時刻刻進化它。 　　Do it often。

緣起

　　上篇博客轉眼已是半年前的了，最近有兩個原因，促使我再次寫博：

　　一是深深感到，在軟件開發行業，有很多我認為已經是“常識性”的東西，可是對很多團隊卻完全沒有體會。敏捷軟件開發已走過十年時間，可是仍未普及，我覺得一個原因正在于此：很多“最佳實踐”，它背后的原理，仍不被很多團隊理解。反過來說，只有行業把這些東西當做“常識”了，敏捷才會真正的普及開來。

　　這些“常識性”的東西，往往很小。很小的實踐，背后卻隱藏著一種價值觀。作為個人來說，如果能跟擁有共同常識、共同價值觀的人共事，無疑會讓每天的工作更加愉快。可是正因為它“小”，導致我一直沒有動力把它們寫下來，直到前幾天參加上海的敏捷沙龍，聆聽了Daniel Teng的演講《Survival》。

　　這個主題演講非常好，講的是個人和組織怎么在當今信息爆炸的年代生存下來。其中有一個觀點：個人在自己的知識更新過程中，要保持“habit to ship”——如同軟件開發中的“持續集成”/“持續交付”，個人所學的知識也要經常“交付出去”，“交付”的形式可以是寫博客、可以是做演講……目的是一樣的：1是尋求反饋；2是小步伐前進，積少成多。

　　很有趣的是Daniel的這個演講所用的PPT，在他演講時并未完成。他的演講本身就在實踐“ship it”的思想——不必等自己的知識體系很完整了，才能去給別人講（知識爆炸的年代，這樣太沒有效率了），有了想法，就可以“交付”給社區，從社區獲得反饋，再做下一步學習的調整，避免方向上的錯誤。

　　這就是促使我再次寫博的第二個原因。 

說明

　　我希望把“我的常識”寫成一個系列，把我認為的在軟件開發中的常識一個個寫出來，并盡量闡明背后的價值觀。有幾點想說明：

　　1， 唯一不變的東西就是變化，“常識”也會變。我所寫的，僅代表我目前的認識水平。

　　2， 我所寫的，不代表全是對的，尤其是不同的團隊，有不同的“context”，沒有放之四海而皆準的東西。因為希望能從社區得到反饋的同時，也希望能拋磚引玉。 

正文

　　這是這個系列的第一篇，其實主題已經在上面的“緣起”里體現了，這篇的正文只舉幾個或真實或假想的案例來說明。

案例一

　　A團隊在進行一個預計3個月后上線的小項目，項目經理排的計劃是2個月后完成開發，然后半個月Alpha測試，半個月Beta測試。項目很小，需求很簡單，似乎沒什么風險。2個月后順利進入Alpha測試，結果發現bug很多，有些細節沒有達到客戶的要求。半個月很快就要過去，于是大家加班修bug。

　　相信很多團隊都經歷過類似的上線前的雞飛狗跳的日子。問題出在什么地方？——團隊把測試放到最后的階段，并且只有一次。如果回到3個月前，項目經理可以做些什么改變呢？Do it often——團隊可以先完成一個小的Feature，然后讓QA針對這個Feature進行測試；同時團隊繼續下一個Feature的開發……如此循環。這其實就是“迭代開發”的概念了。

　　總結：如果一個團隊需要使用“測試階段”來對產品進行質量的保證，那么讓這樣的“測試階段”多一些。

案例二

　　B團隊在重寫一個為期一年的中型應用軟件，舊的應用軟件已經成為遺留系統，維護成本太大，因此公司決定重寫。除了要實現老系統的原有功能外，這個項目還有些特殊的需求：1，該系統跟其他幾個系統有集成，重寫后仍然需要支持。2， 新系統的數據庫會有調整，但老系統的數據需要在新系統上線的時候，無縫地Migrate到新系統中。

　　團隊在經歷了幾個月的開發后，終于完成了所有功能的開發。然后就進入了上線前的準備——1， 把新系統部署到服務器；2， 配置好與其他系統的集成，并且進行測試；3， 把老系統的數據庫備份一個出來，然后運行腳本進行數據庫的升級，然后進行測試。

　　所有這一切都是手工完成。導致的問題是：上線前有很多繁瑣的，讓人精神緊繃的事情，完全靠團隊里個人的能力和細心程度，稍有差錯，就會導致真正上線時的混亂甚至失敗。

　　這其實不是個新鮮的問題，就是ThoughtWorks公司《軟件開發沉思錄》里提到的“最后一英里”的問題。

　　可以做些什么來改善這種狀況，來減輕上線前的壓力，增加上線的信心和可靠性呢？還是Do it often，如果能在每個月、甚至每天、甚至“持續集成”里的每次“代碼check in”，都來演練一下上線前要做的所有這些事，那么到真正上線的時候，團隊就幾乎不會有任何額外的擔心和壓力了。

　　當然要做到這一點，“自動化”是不可或缺的。最理想的狀態，一切都應該“一鍵完成”——團隊需要維護一系列腳本，團隊成員只需要按一個鍵，就能完成“代碼遷出——build——部署——數據庫升級——集成測試”等整個過程。或者，至少，可以把最沒信心、最復雜的環節單獨拿出來做自動化。

　　總結：越是困難的事情，越是要do it early, do it often, do it automatically。

案例三

　　C團隊在做一個新項目，在團隊進入功能代碼的編寫前，架構師已經把架構搭好了。團隊基于這個架構開始進行開發，可是隨著代碼越來越多，需求越來越復雜，大家發現，架構師的架構已經不能滿足需求了。

　　于是團隊向項目經理建議：需要時間來調整、完善框架，這樣對開發更有利。項目經理的答案是：時間不允許了，我們需要把功能全部做完，趕緊發布1.0。架構的完善，以后再說。

　　結果導致什么問題呢：由于架構不夠好，代碼寫的越來越亂，沒有可測性，bug越來越多，在發布1.0之前，團隊花在修bug的時間大概有4個月。

　　于是團隊總結：如果不在前期花2個月的時間來改進代碼的質量，那么就等著在后期花4個月的時間來修bug吧。

　　可是團隊其實還可以做更進一步的總結：為什么改善架構需要向項目經理要額外的時間？架構是什么？架構無非是一些大的設計，軟件開發中無處沒有設計，難道我們開發一個功能時，需要做一個設計，比如這邊想用一個單例模式，也要向項目經理額外要時間嗎？當然不用，寫代碼就是設計，架構無非是大一些的設計，架構不是什么特殊的東西。它可以也應該在編寫Feature時不斷的完善和演化。架構的演化是日常開發的一部分。提前有個架構是好的，然而日常的演化必不可少。這就是“進化式架構”的概念。

結語

　　作為軟件工程師，我們編寫軟件就是因為人腦的運算速度、精確程度、可重復性都不如電腦，因此編寫軟件，用電腦來幫忙干活。可是在編寫軟件的時候，為什么很多人會忽略讓電腦來幫我們驗證我的軟件呢？

　　1，不要完全依賴人來測試我們的代碼——用代碼來測試我們的代碼。

　　2，不要完全依賴人來驗證我們系統的集成——用自動化腳本，用持續集成軟件。

　　3，不要依賴人工一次性的勞動來確保軟件的正確——用分而治之、迭代開發來“反復確保”。

　　4，不要等軟件腐化后再來“重寫”軟件——時時刻刻“重構”它。

　　5，不要期待設計/架構可以一步到位——時時刻刻進化它。

　　do it often。

參考閱讀

　　Daniel Teng：我談迭代 。迭代就是do it again and again。也是do it often的體現。

　　Matin Fowler：有機會就重構。大師最新的關于重構的文章，教導我們：refactor it often。

　　劉未鵬：為什么你應該（從現在就開始）寫博客。經常寫博客。