今天例會(huì)提了個(gè)建議：就是將單個(gè)小模塊分配到每個(gè)人，當(dāng)然不是像涉及的面比較寬的那種功能或者涉及到系統(tǒng)架構(gòu)的東西，其實(shí)我提這樣的想法是有原因的。但是老大們反對(duì)這么做。我的理由很簡(jiǎn)單：1、可能對(duì)于大的公司或者一個(gè)比較成熟的項(xiàng)目這么做是不合適，但是對(duì)于小的團(tuán)隊(duì)或者是處在十分尷尬位置的項(xiàng)目來(lái)說(shuō)，我覺(jué)得是可行的。2、影響開發(fā)進(jìn)度或者失敗的原因通常可以總結(jié)為：（1）需求變更，（2）計(jì)劃不具體管理較混亂，（3）開發(fā)人員不努力或者技術(shù)不過(guò)關(guān)。（4）人員不夠 （5）對(duì)一個(gè)項(xiàng)目或者產(chǎn)品的長(zhǎng)遠(yuǎn)不是很明確。3、其中大家說(shuō)的一個(gè)理由是“一個(gè)人做某個(gè)功能如果該人員離職那么維護(hù)起來(lái)風(fēng)險(xiǎn)太大”，不能說(shuō)沒(méi)有道理，但是我覺(jué)得系統(tǒng)維護(hù)的難易不是人員的問(wèn)題，項(xiàng)目中的人員變動(dòng)是不可避免的，如何減少人員流動(dòng)姑且不論。一個(gè)好的或者清晰的架構(gòu)以及清晰的文檔只要做好交接工作，維護(hù)起來(lái)比一個(gè)不好的架構(gòu)要省很多的力量，如果架構(gòu)不好即使誰(shuí)維護(hù)可能選擇的都是重構(gòu)。記得當(dāng)初我寫某管理模塊的時(shí)候，那時(shí)剛畢業(yè)，技術(shù)很有限，代碼結(jié)構(gòu)太差，最后只好花了很多時(shí)間重構(gòu)了一把。 針對(duì)這個(gè)問(wèn)題的另一面那
文章來(lái)源:
http://blog.csdn.net/mejy/archive/2008/01/21/2056659.aspx