艾偉也談項目管理，大項目的思考

　　引言：進入現在這個我們内部号稱“豪門”的項目已經兩個多月了。現在回想起進入項目前一位前輩的話：“大項目有大項目的問題，但大項目也有很多東西可學“，自己此時深表贊同。兩個月的時間，自己從剛來前兩周的觀察學習，到現在的基本融入，在這個過程中自己有了很多的想法和思考。

　　為什麼測試這麼難寫？

　　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的設計者可以看到了，這就如同你站在原地，你能看到10米外的東西。随着項目時間的增長，這個距離也在增長，在加上中間需求的一些變更，就如同一個小彎，這時候的位置已經不是framework的設計者所能看到的距離了。這個時候framework對于開發限制開始突出，而開發人員礙于修改framework成本太高，很多時候被framework所牽制。既然我們隻能看到10米外的東西，那麼我們為什麼要做100米外的設計呢？

　　其次，framework的設計思想也會随着項目人員的進進出出，項目進度的壓力，大家都沒有實踐仔細的去看framework。framwork的設計思想變的不再清晰，大家開始按照自己的對于framework的了解來寫代碼，後來者更不了解framework，會照那些前面未必正确的了解的代碼來書寫。

　　一個團隊是不僅是在維護一份源代碼，更重要的是維護這個項目所承載的知識。而這些知識不應該隻記在某些關鍵人物的腦中，應該記在所有團隊成員的腦中，更不應該隻記錄在文檔之中。而這知識包括：

架構設計的知識：架構設計的知識隻有進入所有開發人員的腦中，才能得到正确的實作。是以架構設計不應該隻從技術角度考慮，也應該從團隊知識傳遞的角度考慮。一個100的設計，而團隊成員隻能了解30分，那你覺的最後的軟體是多少分呢？

所謂的局部知識：很多時候，一些開發人員覺得我做的東西隻有我一個人在做（比如build腳本），是以我可以選我熟悉的東西就好。而這種所謂局部知識的想法非常不可取，因為當你有這個想法的時候就意味着你變成這個項目的瓶頸。

固定角色：在團隊中固定角色就意味着劃定了各個角色的邊界，而每個角色對于自己角色外的東西已然不是外面的世界很精彩。這個時候很多時候它做得決定都是基于自己的角色，而不是整個團隊的角度。