拙劣的軟體工程－導師與研究生開發模式

    在路的篇幅裡，我闡述了大量讀研時失敗項目的例子。

    為什麼我們的項目做起來總是這麼吃力，很多看似簡單的項目經常胎死腹中，貌似進展很快的項目到最後遲遲不能結束，針對客戶頻繁變動的需求程式員們都顯得如此疲憊不堪，原來的代碼自己都懶的閱讀，修改一處BUG引來無數新的BUG，更改（添加）一個功能可能只有幾行的代碼量，為什麼發布上線卻需要幾個小時的工作量，為什麼上線後，甚至一年後都會發現很多BUG,這些問題一直困擾著我，在經曆了一些項目的實踐之後，我開始總結與反省，閱讀了許多書籍，試圖從中尋找到答案，其中包括：人月神話，程式員修鍊之道，測試驅動開發，極限編程、設計模式等，這些軟體工程的書籍清晰的回答了這些問題，極大地豐富了我的眼界。

    首先，在我們的開發中，我們遠沒有一支穩定的開發隊伍。對研究生來說，開發的優先順序不是最高，經常因為課程、論文或者其他工作被迫從開發的情境裡給拉出來，甚至還有一些研究生在忽悠導師，這對於項目來說是致命的。

    其次，項目的權利與義務從一開始就很模湖，很少有人願意為很不確定的前景而工作。這個問題在公司裡很簡單，我拿工資我這個東西就要弄出來，我就要通過品質保障人員的驗收，在這裡不是這樣，項目開發的費用一般是導師後來給的，開發人員對此一無所知，自然也就缺乏激情。如果導師自己參與項目的設計開發還好，研究生只是跟著幹，研究生不幹了，自己還可以頂，如果導師具備相當的人格魅力，願意學習的研究生還是樂意乾的，導師自己也是QA,可以審核研究生的開發成果。但大多數導師是委託式的，把所有的任務都交給你了，但是，你不清楚你可以得到多少，所以很多人只是在憑個性而工作，幹自己喜歡乾的事，這裡也沒有QA,最後的結果自然而知，即便流產了對研究生來說也沒有什麼可惜，因為他已經得到了鍛煉。

    第三，研究生大多是沒有項目經驗的，前面也沒有積累，代碼大多是在心血來潮下寫出來的，沒有設計，也不考慮擴充，經常後來自己都讀不懂，缺乏整理東西的習慣。舉個例子，項目中要用到一個複雜的Applet,這個Applet在用java寫完後，還需要數位簽章，同時applet的工作模式如果變了，還需要更新一些其他的東西，換句話說，如果使用者需求變動導致applet的代碼和工作模式變了，雖然可能只是幾行代碼的工作，但是開發人員必須進行重新數位簽章和更新一些其他的東西（假設開發人員是個新手，他甚至都忘了上次是如何數位簽章的，這次他必須重新去找資料。重複工作的痛苦對於程式員來說是不言而喻），在再次編譯簽名和更新相關東西後，可能許多時間就過去了。“改動怎麼就這麼麻煩呢？”。其實這隻是一個簡單的項目自動構建的問題，只要把所有重複的事情都提取出來，讓電腦去幹就行了，但是一個新手，往往會陷入前面痛苦的泥沼。

    第四，薄弱的測試和品質保障。測試應該在項目開發中佔有很重要的比例，導師與研究生的開發弱化了這個環節，這裡不再深述，沒有專業的測試，一年之後還會發現BUG就沒什麼稀奇了。再者前面提到的品質保障，缺乏平時關於軟體品質的監督，所有的問題在互動之日接踵而至，項目遲遲延時就不足為奇了。

    成功的導師與研究生的開發，需要解決的問題太多，除了上述的以外，電腦研究生的培養模式也是值得深思的。