引言：進入現在這個我們內部號稱「豪門」的專案已經兩個多月了。現在回想起進入專案前一位前輩的話：「大專案有大專案的問題，但大專案也有很多東西可學「，自己此時深表贊同。兩個月的時間，自己從剛來前兩周的觀察學習，到現在的基本融入，在這個過程中自己有了很多的想法和思考。
為什麼測試這麼難寫？
tdd的開發實踐保證了**的可測試性，那麼當tdd的t變的非常難寫的時候，是不是現有的**可測試性已然變的非常差呢？其中一些非常典型的場景就是：
kent beck說過，當你的測試出現問題，退後一步往往就是乙個設計問題。
很多人開發人員迷戀framework，迷戀framework設計的優雅以及對於開發的便利。我曾經也是其中一員，但是現在我站在了這個觀點的對立面。
首先，專案初期的時候framework的設計在大部分都是猜測，剛開始的時候這些猜測大部分都很準，因為這個時候距離是framework的設計者可以看到了，這就如同你站在原地，你能看到10公尺外的東西。隨著專案時間的增長，這個距離也在增長，在加上中間需求的一些變更，就如同乙個小彎，這時候的位置已經不是framework的設計者所能看到的距離了。這個時候framework對於開發限制開始突出，而開發人員礙於修改framework成本太高，很多時候被framework所牽制。既然我們只能看到10公尺外的東西，那麼我們為什麼要做100公尺外的設計呢？
其次，framework的設計思想也會隨著專案人員的進進出出，專案進度的壓力，大家都沒有實踐仔細的去看framework。framwork的設計思想變的不再清晰，大家開始按照自己的對於framework的理解來寫**，後來者更不理解framework，會照那些前面未必正確的理解的**來書寫。
乙個團隊是不僅是在維護乙份源**，更重要的是維護這個專案所承載的知識。而這些知識不應該只記在某些關鍵人物的腦中，應該記在所有團隊成員的腦中，更不應該只記錄在文件之中。而這知識包括：
架構設計的知識：架構設計的知識只有進入所有開發人員的腦中，才能得到正確的實現。因此架構設計不應該只從技術角度考慮，也應該從團隊知識傳遞的角度考慮。乙個100的設計，而團隊成員只能理解30分，那你覺的最後的軟體是多少分呢？
所謂的區域性知識：很多時候，一些開發人員覺得我做的東西只有我乙個人在做（比如build指令碼），所以我可以選我熟悉的東西就好。而這種所謂區域性知識的想法非常不可取，因為當你有這個想法的時候就意味著你變成這個專案的瓶頸。
固定角色：在團隊中固定角色就意味著劃定了各個角色的邊界，而每個角色對於自己角色外的東西已然不是外面的世界很精彩。這個時候很多時候它做得決定都是基於自己的角色，而不是整個團隊的角度。
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...