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