讓你提前認識軟體開發(39)：軟體研發之殇

第3部分 軟體研發工作總結

軟體研發之殇

        在經典著作《人月神話》中，作者提出了一個觀點：絕大部分的軟體研發項目都不能按期完成。我工作也有一段時間了，發現這确實是一個不争的事實。我所從事的項目中，能按期按質完成的還真的很少。這是什麼原因呢？我工作不夠努力嗎？非也。為了完成任務，我也是經常加班加點地工作，生怕惹惱了上司而飯碗不保。

        軟體研發是一個系統的工程，是由很多環節組成的。你一個人把自己那部分工作做好了，還不足以保證整個系統能正常運轉。在本文中，我按照軟體的生命周期(如下圖所示)來分析軟體研發的各個階段會出現的問題，供大家參考。

        第一，概念階段。

        在這個階段，主要是售前人員(也可能有其他稱呼)與局方(也就是客戶)談合同，弄清楚他們到底需要一個什麼樣的東西，并回報給系統工程師(System Engineer，簡稱SE)，SE再寫成需求說明書給軟體開發人員。

        軟體研發項目出現的問題，很大部分要歸咎于這個階段。問題越是發現得早，解決起來就越是容易。而這個階段中一個小的問題，在後期也會被放得很大。

        這個階段出現的問題主要有以下幾個：

        (1) 售前人員為了“讨好”局方，簽了一些令人“匪夷所思”的合同。社會競争越發的激烈，在資訊技術領域尤其如此。在衆多公司的競标中，能夠簽到合同實屬不易。為了簽到合同(同時滿足公司考核名額)，售前人員總是在客戶面前拍胸脯，不惜以各種承諾、豪言壯語換回那利潤已經薄得很可憐的合同。在這些合同中，有很多是有待考究的，需要反複思量的。可大部分售前人員都不懂技術，簽完合同之後就“領賞”去了，這就害苦了開發人員，也影響了産品研發的進度和品質。

        (2) 局方人員高高在上，經常将自己的想法變來變去。就像現在雇主招聘應屆生一樣，局方(也就是所謂的甲方)在衆多的公司(俗稱乙方)中進行選擇，不僅将合同的金額壓得很低，還隔三岔五地将售前人員叫過去，讓他們修改需求說明書。說得不好聽，這是不誠信的表現。每當這個時候，總會有人冒出一句：“誰讓人家是甲方呢？”

        (3) 系統工程師(SE)沒有将需求寫清楚，沒有表達出局方人員的意思。每個人對事物的看法不同，寫出來的東西就會有所不同，更何況從局方人員到售前人員，再到SE，中間已經轉了好幾次，出現表達的差錯也是在所難免的。而SE有時又比較的“懶”，不想與局方人員進行深入的交流，認為自己已經明白意思了，這也導緻後期軟體功能不合局方之意，又要推倒重來。

        我們經常說，要将壞的事物扼殺在萌芽狀态。在概念階段，也就是軟體雛形的形成階段，一定要将軟體的功能搞清楚，這樣也省去了後期的很多不便與折騰。

        第二，計劃階段。

        在此階段，主要是根據需求說明書來進行軟體的詳細設計，确定程式的執行流程及相關功能子產品。這也是軟體開發工程師要幹的事情。

        在這個階段，可能出現的問題如下：

        (1) 軟體詳細設計完成之後，不經評審就馬上開始編碼。公司有規定，詳細設計要經過評審之後才能啟動開發。而很多時候，為了趕進度(我個人比較讨厭“趕進度”這三個字)，這個環節也省去了，直接導緻開發人員按照個人想法來設計軟體，出現了了解上的偏差，最終導緻客戶驗收不通過。為了保證軟體的正确性，一定不要吝啬那麼一點點時間，要請有經驗的同僚來評審自己的詳細設計。所謂的“磨刀不誤砍柴工”，也就是這個道理。

        (2) 軟體開發人員為了應付評審，寫出了詳細的程式流程，可啟動開發之後，偏離了之前的想法。這在研發過程中也是經常出現的。當我們照着軟體詳細設計閱讀代碼的時候，發現程式流程與文檔中的流程圖不相符，而且有時偏差還比較大。這就是開發人員個人素質的問題了。在編碼的過程中，一定要盡量忠于自己的詳細設計，而在确實需要修改的時候，要同步更新詳細設計文檔。

        在很多項目中，設計階段往往與開發階段合二為一，一邊開發，一邊設計。我個人認為這是不恰當的，一定要對程式流程有全面的了解之後再開始編碼。

        第三，開發階段。

        開發階段，就是将想法用程式來實作的階段，也稱為編碼階段。這個階段的重要性不言而喻，問題出得最多的也是這個階段。

        隻要是參加過軟體開發的人，都會知道這個的階段的問題會出在哪裡。我總結了一下，應該有以下方面：

        (1) 不按公司的程式設計規範來辦事，編寫出隻有自己才能讀懂的代碼。這是最令人頭疼的事情。當我們打開前面一個開發人員編寫的程式檔案，一眼就能夠看出其專業素質和态度。在我閱讀過的程式中，真正符合程式設計規範的極少，大部分都存在這些問題：無注釋、變量和函數命名不規範、程式邏輯混亂、程式版式不工整等。在前面的文章中，我對這方面的内容也做了詳細的說明。總之，不管怎樣，規範是必不可少的，盡量不要破壞“遊戲規則”。

        (2) 不用最簡潔的方式來程式設計，故意賣弄自己的水準。很多開發人員水準比較高，他們喜歡用一般人不知道的方法來寫代碼，以表現自己的能力。但他們忘了，我們是要用代碼來實作産品的功能，而不是來展現自己的水準有多高(展現的地方是網上的各種程式設計大賽)。當你的後任來讀到令人費解的代碼時，他們絕對不會贊美你的水準有多高，而會在心裡罵你。在很多著作中，都對這方面的内容進行了闡述，一個中心思想就是：我們要用最簡單、最通俗易懂的方法來編寫程式。

        (3) 不注重對程式進行自測，以為測試就隻是測試工程師的事情。在很多開發人員的觀念裡，自己隻管把代碼寫好就行了，剩下的測試任務有專門的人來完成。現在，大公司都在強調産品品質，強調對産品進行充分的測試。對于開發人員，要求則是要自測充分，盡量保證送出到測試部的程式是零差錯的。也許有很多人看不起搞測試的，也不想自己找自己的問題(測試就是要找出問題)，但這并不是喜不喜歡的問題，是職業素質對我們的要求。

        以上三點幾乎是開發人員的通病，也是提高軟體品質的最大障礙。

        第四，驗證階段。

        驗證階段，也可以叫做測試階段，主要是由軟體測試工程師來對開發工程師編寫的程式進行測試，以保證軟體品質。測試方式分為白盒測試和黑盒測試兩種，大部分到軟體公司實習過的人應該都知道。

        本來，測試人員和開發人員應當是“親如兄弟”，大家合力來共同保證産品品質，而現在的情況卻相反，開發部和測試部有時是“苦大仇深”，互不往來。開發的看不起測試的，認為那個沒有什麼技術含量；而測試的也以找到開發漏洞為榮，很多項目甚至設定了名額，每個月要提多少故障單(提單就是發現了開發問題)，搞得開發人員是心神不甯，很是反感。

        如何解決這個問題呢？首先，公司的考核機制要變，不能以什麼提單數量來考核員工；其次，開發人員和測試人員要多溝通交流，不要“老死不相往來”；再次，要以傳遞出高品質的産品為共同目标，而不是整天以“抓小辮子”為樂。

        當然，我上面的表達可能有不當的地方，但多多少少說明了一個事實：開發和測試應合作多于對立。

        第五，釋出階段。

        測試完成之後，就應當将産品傳遞給客戶，請他們來驗收。在這個時候，最怕的就是他們當場變臉，說産品功能不滿足他們的要求。這種情況還經常出現，導緻很多項目出現嚴重的虧順。

        為了避免此類事情的發生，在軟體的開發階段，相關負責人(特别是SE)一定要起到協調溝通的作用，将已實作的功能讓客戶知道，請他們确認這是否是他們想要的。可以看出，交流溝通在哪裡都很重要。

        第六，營運維護階段。

        産品商用之後，公司還要對之進行維護，出現了問題要及時修補更正。一般說來，隻要産品測試驗證得比較充分，出現問題的幾率還是比較小的。怕的就是客戶腦袋發熱，一會兒想出這個，一會兒又想出那個，這樣開發和測試人員又要忙碌起來了。

        如上所述，軟體研發是一個複雜的系統，隻有系統的每一部分都正常運轉，整個系統才能夠一切正常。一旦某個環節出了問題，那麼系統就猶如漏水的輪船，如不及時修補，終将沉入大海。

        都說IT從業人員很累，不管是做技術的，還是搞銷售的。确實是這樣，隻要産品有一個小小的問題，那麼上面所說的六個階段又要重新走一遍，能不累嗎？

        本文以作者的工作經驗為基礎，結合個人的感悟，表達了對軟體研發項目的一點看法。不當之處，還請各位批評指正。總之，縱使夜晚多麼的黑暗，明天太陽還是會照常升起。工作主要是看心态如何，你覺得呢？