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

標籤：style   blog   http   color   strong   檔案   

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

軟體研發之殤

 

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

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

 

        第一，概念階段。

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

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

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

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

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

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

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

 

        第二，計劃階段。

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

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

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

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

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

 

        第三，開發階段。

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

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

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

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

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

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

 

        第四，驗證階段。

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

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

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

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

 

        第五，發布階段。

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

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

 

        第六，運營維護階段。

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

 

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

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

 

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

 

 

(本人微博：http://weibo.com/zhouzxi?topnav=1&wvr=5，號：245924426，歡迎關注！)