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

標籤：style   blog   http   color   ar   strong   檔案   sp   div   

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

軟體研發之殤

 

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

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

 

        第一，概念階段。

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

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

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

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

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

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

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

 

        第二，計劃階段。

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

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

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

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

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

 

        第三，開發階段。

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

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

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

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

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

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

 

        第四，驗證階段。

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

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

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

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

 

        第五，公布階段。

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

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

 

        第六，運營維護階段。

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

 

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

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

 

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

 

 

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

 

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