軟件項目中錯綜復雜的問題

軟件項目中錯綜復雜的問題

在《C++頭文件風波》中提到我所在的team使用C++開發(fā)時遇到遇到的一些管理上的問題。對于軟件開發(fā)項目來說，評價項目是否成功的因素恐怕最關鍵的就是

·是否能按期完成

·是否能夠保證質量

按期完成的事情就不要提了，到目前為止我還沒有看到過能夠按期交付的項目。原因很多也很復雜，大概有人讀過《人月神話》的焦油坑那節(jié)就知道怎么回事，連精英匯聚的IBM360系統(tǒng)開發(fā)都能出這么多的問題，就不要指望我們這些平庸之輩組成的團隊還能能夠創(chuàng)造什么奇跡。這個觀點也許有點消極，但是事實的確是這樣的。雖然很多人在想辦法解決軟件開發(fā)中的各種各樣的問題，但結果卻仍然不那么理想。

軟件質量不能得到保證也是問題。軟件質量衡量的標準有很多，你可以從不同的側面說出來一個優(yōu)秀的軟件項目所能創(chuàng)造的價值，比如，健壯性，彈性，可移植性等等。問題是，很少有人或者團隊在項目開發(fā)的時候能保證取得他們想要的所有質量特性?！跋劝咽虑樽鞒鰜恚缓笤诎阉骱谩?，也許這也是個說辭。但現(xiàn)實情況是，如果沒有良好的迭代流程，幾乎在每一次版本變更或者移植的時候都會將上個版本完全拋棄。這就是我們遇到的問題。此外，第一個版本似乎永遠是要被扔掉的——這句話也是《人月神話》來的。扔掉某個軟件版本并不是很可怕的事情——比如用腳本語言開發(fā)的用來引發(fā)討論和idea的原型，可怕的是，有的項目展開了都有一段歷史了，版本變更的時候源代碼還在劇烈震蕩。你找不到清晰的版本線，你拿捏不了這玩意兒為啥要這么做。我遇到的一個比較極端的例子是一款瀏覽器的開發(fā)，main函數(shù)所在的那個文件有6000多行?。。《疫@玩意兒是用C＋＋寫的，雖然按照《Codecomplete》的說法，C++代碼比較verbose（如果c語言是1，那么C＋＋的代碼量是2.5左右），但也不至于到這種地步。很顯然，這個瀏覽器在最開始的時候就沒有經(jīng)過良好的設計。有人把GUI的處理，HTTP通訊，業(yè)務邏輯等等混雜一氣寫到了同一個文件當中。于是造成的結果是，在開發(fā)下一個版本的時候，總是有大量的代碼要被重寫，6000行的源文件，幾乎是全部被拋棄。日本人有保守謹慎的做事風格，因為他們認為上一個版本是能夠使用的，所以，下一個版本應該仿照上一個版本來寫。于是繼續(xù)制造一堆根部不可讀平且繼續(xù)會被在下一個版本中拋棄的代碼。就是再也樣。代碼重用如果有問題，恐怕想做到敏捷開發(fā)也是不可能。比如，新版本變更中僅僅影響到了圖形界面——這是最常見的情況，例如從GraphicToolkit從gtk換到Enlightenment，或者再從Enlightenment換到miniGUI上，如果在第一個版本中就搭建了一個良好的結構的話——BridgePatten是一個解決方法——以后的版本之需要按照簡單的體替換規(guī)則做些改動就可以了。這是一種理想狀況。我想說的是為什么在現(xiàn)實中無人關心這件事情。

每次新項目開始，總會有很多部門的不同人員加入進來，關鍵是每次新項目的項目經(jīng)理都在換！這個項目的項目經(jīng)理不需要對下一個版本負責，他關注的只是現(xiàn)在，當下。他需要的是只要能把自己的task完成，至于以后怎么辦，“那不是我的事情”。

優(yōu)秀的軟件開發(fā)人員實在太少，即使能夠找到，也會因為論資排輩的“科層”制度被埋沒。我一直認為在研發(fā)上構造職權的層次結構是非常SB的行為。但是，往往會發(fā)生屁股指揮大腦的行為。最狠毒的老板恐怕是下面這種人。

[This]remindsmeofatrue“Dilbertmoment”afewyearsago,whenmy

(obviouslynon-technical)bosscommentedthatheneverunderstoodwhyittookmonthstodevelopsoftware.“Afterall”,hesaid,“it’sjusttyping.”

——來自CodingHorror。

被公司放出去的項目經(jīng)常難于管理。曾有Moto的VP大聲疾呼，一定要把發(fā)放到亞洲地區(qū)的設計和軟件開發(fā)工程收回才能拯救Moto的手機部門——雖然他們已經(jīng)這么做了，但是很顯然最終還是臣服于Google的Android平臺。以我接觸的項目為例，公司采用外派人員來參加項目開發(fā)，這樣作的好處是不需要養(yǎng)那么多人而在長期來看是降低了人力成本，但弊端卻是數(shù)不勝數(shù)！因為契約的關系，外派人員通常是按照計時或者計件收取費用的，所以，他們在項目之中呆的時間越長或者生產(chǎn)的代碼量越大，他們獲得的薪水就會比較高。很顯然，這個利益獲得方式與項目的進展不在同一條道路上。項目延期，代碼重寫對這些開發(fā)人員來說是“利好消息”。如果原動力都不一致，怎么能保證一個團隊齊心協(xié)力的工作？

人員替換和流逝過于快速。而恰恰因為傳統(tǒng)的公司風格——以“管理人”為管理的核心，而不是把“管理知識”作為管理核心來看待——導致了人力資源流失直接造成產(chǎn)品研發(fā)能力的流失。代碼，文檔等內容管理被放在一個很不起眼的地位上，這些事情被認為只是輔助工具，而不是管理核心和作業(yè)對象，一遇到問題你得到的答案不是“參照XXX文檔/標準”，而是“去問一下XXX大俠”。其結果是，人走了，軟件版本會跟著出現(xiàn)斷層。我一直認為對一家軟件開發(fā)團隊而言，最重要的財富就是良好的文檔和優(yōu)秀的代碼，如果舍本逐末的只把著眼點放在最后產(chǎn)出上，那將又是一個只要葫蘆不要藤的故事。

設計理念和方法在團隊中不能取得一致。大學的時候學過一門課程叫《系統(tǒng)分析與設計》，我至今覺得這門課是我大學學習的最重要的課程之一。比較丟人的事情是，第一次考試我竟然把它掛掉了，掛課原因不明，呵呵。這本書中提供了（至少）兩套系統(tǒng)分析和設計的方法——雖然不夠完善，這個先按下不談——隨便按部就班的堅持一套作下來都會對你要完成的事情有比較清晰正確的認識。但問題是，這樣的方法論在一個團隊之間不是所有人都了解和認同的。往往設計方法的討論結果是雖然作軟件架構的人聲明這個應該那樣那樣，雖然開發(fā)人員也只能按照那個方法去做了，但卻不能完全理解他的理念，造成很多偏差和錯誤。所以我有時候想，是不是與大學同班同學開一家公司會比較強大，哈哈哈?！断到y(tǒng)分析與設計》這本書雖然闡述了一套普遍的方法論，但遺留問題是，它只能作出對現(xiàn)事世界的直接描述，而這種直接描述只能適應現(xiàn)在的情況，而不適用于變化不定的未來。分析模型和設計模型之間存在一定的距離，而這個真空地帶只能依靠工程師的經(jīng)驗后者新的方法論來填補，到目前為止我覺得比較有指導意義的一本書是《設計模式》，具體的算法實現(xiàn)以及更加深入一點的實現(xiàn)部分最好的教本恐怕是Knuth大俠的《Theartofcomputerprogramming》，當然這個又是方法論的話題，扯遠了。