大項目的思考:不要讓框架成為團隊創新的殺手
為什么測試這么難寫?
tdd的開發實踐保證了代碼的可測試性，那么當tdd的t變的非常難寫的時候是不是現有的代碼已然變的可測試性非常的差呢?其中一些非常典型的場景就是
test的setup太難，而造成這個的一個主要原因就是貧血的model和***的service。因為model沒有行為，所以很多時候可以通過測試model來完成的測試，卻不得不通過測service來完成，而***的service做的事情又太多，需要依賴的東西也太多，而這個時候你本來一個簡單的測試就為了setup這個service的依賴而變成一個巨型的測試。
你總有做behavior verification的沖動，而behavior verification本身就是邪惡的。記得《xUnit test pattens》這本書說到，”任何需要白盒測試的時候，往往都是代碼設計的問題“。
Assert太多了，一個簡單的測試卻要有一堆的assert語句。問題很簡單，被測試的對象承擔了太多了職責。
脆弱的測試，這里我看到了有兩個原因：***，共享的fixture;第二，想當然的assert，比如你只是想assert這個collection有沒有你要的那個instance，因為你想當然的認為此時collection里只有一個instance，造成后人對于這個collection加入另一個不同instance依然會break你的測試。
Kent Beck說過，當你的測試出現問題，退后一步往往就是一個設計問題。
項目初期設計framework有好嗎?
很多人開發人員迷戀framework，迷戀framework設計的優雅以及對于開發的便利。我曾經也是其中一員，但是現在我站在了這個觀點的對立面。
首先，項目初期的時候framework的設計在大部分都是猜測，剛開始的時候這些猜測大部分都很準，因為這個時候距離是framework的設計者可以看到了，這就如同你站在原地，你能看到10外的東西，隨著項目時間的增長，這個距離也在增長，在加上中間需求的一些變更就如同一個小彎，這時候的位置已經不是framework的設計者所能看到的距離了。這個時候framework對于開發限制開始突出，而開發人員礙于修改framework成本太高，很多時候被framework所牽制。既然我們只能看到10米外的東西，那么我們為什么要做100米外的設計呢?
其次，framework的設計思想也會隨著項目人員的進進出出，項目進度的壓力，大家都沒有實踐仔細的去看framework。framwork的設計思想變的不再清晰，大家開始按照自己的對于framework的理解來寫代碼，后來著更不理解framework，會照那些前面未必正確的理解的代碼來書寫。
團隊!團隊!
一個團隊是不僅是在維護一份源代碼，更重要的是維護這個項目所承載的知識。而這些知識不應該只記在某些關鍵人物的腦中，應該記在所有團隊成員的腦中，更不應該只記錄在文檔之中。而這知識包括：
架構設計的知識：架構設計的知識只有進入所有開發人員的腦中，才能得到正確的實現。因此架構設計不應該只從技術角度考慮，也應該從團隊知識傳遞的角度考慮。一個100的設計，而團隊成員只能理解30分，那你覺的***的軟件是多少分呢? 當一個idea無法完全遵從frame的時候,要么修改frame要么無視frame，不要讓框架成為團隊創新的殺手。
所謂的局部知識：很多時候，一些開發人員覺得我做的東西只有我一個人在做(比如build腳本)，所以我可以選我熟悉的東西就好。而這種所謂局部知識的想法非常不可取，因為當你有這個想法的時候就意味著你變成這個項目的瓶頸。
固定角色：在團隊中固定角色就意味著劃定了各個角色的邊界，而每個角色對于自己角色外的東西已然不是外面的世界很精彩。這個時候很多時候它做得決定都是基于自己的角色，而不是整個團隊的角度
原文鏈接：http://www.cnblogs.com/feihe/archive/2011/04/27/2031228.html
【編輯推薦】
