軟體開發，標準化流水線式開發的實施構想

轉自羅振輝的部落格

       近日看到一篇博文，討論標準化流水線開發模式的話題，但是這篇博文僅僅提出這個問題，未見回應。

       這其實是一個很大的問題，我從事軟體開發這麼多年，仍然未見到國內有任何一家公司真正做到，這個問題也是我一直到思考的。一直以來我也嘗試推行這種模式，但是仍然未見起色，從中我不僅學習到一些經驗，但是也深知其困難。通過這篇博文來跟到家分享下我的經驗。

Ø         一個問題、什麼是標準化和流水線開發模式，為什麼要實施？

       可能大家對標準化和流水線開發模式還不大清楚，我們先來細細闡述一下。標準化和流水線開發模式就是使得軟體模組標準化，軟體開發流程像生產車間流水線作業 一樣，所有的軟體工程師只需要根據軟體設計規格書去模組庫選擇適當的模組（即原材料），然後編寫程式進行拼裝、測試、釋出即可。

       無可厚非，這種開發模式，效率是極高的，而且對程式設計師水平要求也是極低，這樣不僅僅可以提高軟體系統的效率，而且也可以大大的降低人力成本，完全實現軟體大批量式生產和開發，因此實施這種模式對一個公司來說確實很迫切。

Ø         又一個問題、國內軟體公司為什麼遲遲未能成功實施這種開發模式呢？

       首先需要說明的一點，大家切不要以為國內的公司不想實施，其實做夢都在想，但是為什麼沒能成功實施呢？我認為有以下幾點；

       國內大部分公司的目標和需求都不明確。大家可以發現國內的公司有一個最大的特點就是產品種類多，其實這個也不算什麼，最要命的就是，種類多還行業多。比如 說有些公司既有煤礦安全監控的產品，又有電子消費方面的產品，甚至還有ERP方面的產品。其實細細觀察，這些公司的產品卻沒有一個是已經具備一定規模的， 可以想象，這些公司在這些相應的行業中的積累似乎足夠淺，提煉這個行業的軟體模組基本不可能，或者就是模組根本達不到通用的標準。因此大家常常會發現，公 司的大部分工程師是在修改原由的模組來滿足各類客戶的需求，這樣久而久之使得軟體模組已經很難統一，維護異常困難，人疲馬乏，還怎麼實現標準化和流水化 呢！其實總結一句就是，定製產品就是使得公司無法成功實施標準化和流水化開發模式的原因，可能這樣說來說去又回到“雞”和“蛋”的問題，大家細細琢磨吧！

       國內公司的管理層和程式設計師還太年輕。在這麼多的公司當中，大家其實可能發現，國內的公司都是青春期的公司，一些工作一兩年的就是什麼系統工程師，工作兩三 年的就當個專案經理甚至部門經理，可以想象，在中國這種環境下，這樣的職位晉升從此斷送這些人的技術前景和積累。從此這些人就開始不斷的根市場打交道，學 會市場卻忽略了技術的學習和積累，如此長久下去，最終、公司的高層雖都具備市場的眼光，但卻斷送了工程技術的創造力，其慢慢就無法把握工程的基層開發流 程，更不用去談什麼標準化和流水線作業了。這就是為什麼有些公司發展數十載，再也發展和壯大不下去的原因——因為他們已經陷入了人才怪圈的迴圈，此後就會 發現人才流動頻繁，人才週期縮短等現象。

       國內公司缺乏專案總結和軟體重構的意識和投入。國內很多公司都是靠定製專案生存的，有些專案來的很緊急，需要迅速開發出來。大家都知道，這種快速的開發完 全時間建立在成熟的技術至上，由於時間緊急，釋出可執行的軟體是最為緊迫的，大家工作的目的就是趕時間、趕工程、趕“釋出”，然而如此往復，不僅人困馬 乏，而且我們時常發現，軟體釋出後，一旦獲得使用者認可，那麼這個專案就算是完成了，然後專案組進行簡單的專案總結之後就將專案組成員遣散到其他專案中去， 也不對系統進行重新分析和模組進行重夠構、甚至不做任何歸檔。這樣、在這個專案的中獲取的經驗就完全屬於專案組成員的個人經驗，而非公司技術積累，一旦某 個程式設計師離職，那麼在專案中積累的一些經驗（軟體模組）就隨之不復。IT行業，在國內來說，至少是一個高流動性的行業，因此對於國內IT企業來說，技術積 累也是異常的困難。其實就我看來，一家人才流動性比較高的企業，其10年的行業技術積累還不如一些稍微穩定的公司6年的積累。

Ø         那麼我們應該如何實施軟體標準化和流水線開發模式？

        在我的軟體開發生涯當中，我時時刻刻在思考如何將實施軟體標準化和流水線開發模式。我先後從事過應用開發、基礎裝置驅動開發、核心開發，每個開發過程我都 試圖尋找其中的開發模式，儘量作到標準化和流水線作業，以提高開發效率。這些年雖然未的到一個成熟的方案，但也獲得一些經驗，那我們來分享下吧；

          第一、  開發過程儘量做到標準化，將文件作為開發過程的里程碑。

         在一些急行軍式的專案開發過程中，很多時候都會將文件忽略，或則就是隻有少量的文件。軟體開發過程也沒有，需求分析、架構設計、詳細設計等過程，只是專案 一上來就開發編寫程式碼。這樣專案小還好說，如果專案比較大的話，那麼到開發的後期就將無法控制了。記得前些年，我開發一套財務系統，當時是第一次作為專案 負責人，時間比較緊，因此拿到專案需求之後，就立馬組織人員進行簡單分析、模組劃分之後就開發編寫程式碼，1.5月之後，我們順利地將軟體開發出來了，測試 之後就部署到伺服器上，之後我們就沒有再過問這個系統。一天我的BOSS，突然給我電話，說財務系統導致虧損18萬，當時我就驚呆（並不是因為金額，而是 頭腦中無一點頭緒），之後就立刻組織人員對程式碼進行復查，當我再次那到這些程式碼的時候，似乎這些程式碼已經很陌生了，因為沒有文件，程式裡一些複雜的演算法已 經忘光了，無根無據，只能從頭到未反覆演算演算法過程，那段痛苦的時間，每每提起都讓人毛骨悚然。之後，在任何專案中開發中，我都儘量將開發過程標準化，以 此避免這種類似的事情發生。

         軟體標準化和流水線開發模式的目的是要進行大規模大批量軟體產品開發，在這種前提下，如果軟 件開發過程不夠標準、文件不夠齊備，那麼公司就需要投入多倍的技術支援來彌補這些缺損、解決這種“無根無據”的問題。因此軟體標準化和流水線開發模式先要 將軟體開發過程標準化、將（重要）文件作為開發的里程碑。

          第二、  將軟體模組更抽象、更細化，層次劃分更合理。

         在軟體構架的時候，將軟體進行層次劃分，模組細化十分重要。以前看過一本書《設計模式》，一句話總結這本書的內容就是“層次劃分、模組抽象和細化、高內聚低偶合”。就標準化和流水線開發模式而言，這更是重要的，也是實施的前提。

        前些年在開發一些管理系統的時候，每次看到我的一位老師（重慶市著名的資料設計專家——王家偉）發給我資料邏輯模型的時候，總是會發現這個模型有些地方總 會和上一次的模型的某些地方相同的，比方說使用者管理模組。這樣、我以前編寫的模組程式碼就能完全複用，節省了這部分的開發時間。當時我就在想，如果每個模組 都能抽象、細化成經典的模組，那麼在下次開發的過程中我們就能直接引用，那該多節省時間啊，新的專案真正需要開發也就是業務層了。

        第一次開發管理系統的時候，我一直對MVC模式無法駕馭，雖然口談論足，但是未得其然。第一個專案之後，我又參加了另外一個稍微大一點的專案，跟著一個資 深的工程師開發，當他給我專案設計書的時候，提出了四層級別的MVC模式，Model、DAL、BLL、Web四層開發模式。這引起我對ＭＶＣ模式的深 思，隨著專案經驗增多，我慢慢才體會到，MVC模式是一個經典的模式，本身並沒有什麼，它的目的就是告訴你，在軟體設計的時候要對軟體進行分層，降低系統 的模組和層次之間的偶合度，在後期面的開發過程中，最多時候我還設計了８層ＭＶＣ開發模式。

       後來我慢慢發現，一個好的經典的模組應用，一個恰當的系統層次模型往往會使得的整個專案開發週期大大縮短、穩定性大大增高。因此、我認為、標準化和流水線開發模式，如果離開了標準（經典）的模組和合理的層次結構，那麼也就是“口談論足，未得其然”罷了！

       第三、  將專案總結和模組標準化、軟體重構、模組抽取納入到開發週期中。

       就像上面的敘述一樣，很多公司為了趕專案，往往忽略了後期的專案總結、軟體（模組）重構等方面的工作。

       有些專案開發經驗的程式設計師就會發現，客戶的需求總是變化的，以前專案中的一些相似模組總是需要有些改動才能適用新專案的需求。

       確 實如此，我也總是遇到，但是後面我改變方法了，每次專案結束之後，我都會對專案總的一些經典的模組進行分析、重構、最終抽取出來建立自己的模組庫，下次用 的時候，就可以直接採用，或則稍做少量的修改就能符合新的需求。這種方法我已經獲得一定的見效，並且屢試不爽！

       前不久，我經歷過一個專案，需要開發一個波形圖繪製的模組，大家都知道這個模組並不複雜，很多人只需花費一個上午就可以完成。也不差、很快我就開發完成 了，併成功應用到系統當中去了。但是，著並不算什麼，為了讓這個模組更加健壯和適應後期的需求，我仔細分析了，後面我發現，這種波形圖模組，少不了座標選 項、少不了波形回查（重現）、少不了波形圖走勢記錄等功能，因此我以經典的模型圖類派生了三個子類，形成波形圖較為經典的模組。這個模組在後期也得到了很 好的應用和驗證，節省了很多不必要的時間。

       標準化和流水線開發模式總是要將軟體需求預先預料，以適應更加廣闊的需求，那麼專案總結和模組標準化、軟體重構、模組抽取就是軟體開發中的“未雨綢繆”，因此建議將其納入到開發週期。

      第四、  建立公司的模組庫，制定軟體開發流水作業模型，並建立培訓單位。

      最後一個話題，有了上面的開發過程標準化、模組抽象、模組重構和抽取，如果我們都這樣做到了。那麼就公司而言，就必須做好技術積累的相應措施了！

      有了模組，公司就必須建立模組庫，並進行分類管理，如GUI庫、控制協議庫、業務邏輯庫等。如果公司10年如一日的堅持模組庫的建立，如果以平均1000 個程式設計師的規模計算，那麼整個庫將涵括1萬個經典子模組庫，這些模組就是軟體的構件，也是軟體標準化和流水線作業的原才料和基礎，就相當製造業工廠生產線 的螺絲。

      模組庫一旦形成，就必須建立軟體開發流水線作業模型，其實也就是新的適合公司的軟體開發流程。如下過程如何；

{《需求分析》—《模型設計》—《架構設計》—《模組複用設計》—《詳細設計》—《編碼》—《測試》—《釋出》—《專案總結、新模組重構和抽取》—《模組庫歸檔》}

      如果模組庫和流水線模型建成，那麼建立培訓機制就更顯重要，對於新員工來說，讓他們瞭解專案開發過程當中能夠使用的資源比什麼都重要，這樣可以避免做無用功。

至此一個簡單的標準化和流水作業實施方案已經趨於完成，最後介紹一下測試。

Ø         測試也需要標準化，建立標準化、自動化、壓力測試部門。

       很多公司都不太注重測試，很多公司即使有了測試，也有些行同虛設，不得其要點。在標準化和流水線開發模型當中，測試顯得更加重要，其實大家都可以發現，在 真個專案週期中測試所佔用的時間都是真個週期的40%，無可厚非，如果不能精簡這部分的時間消耗，那麼標準化和流水線實施的意義也就大大折扣。

       就想我以前的一篇文章中介紹的一樣，其實試分析一下，現在公司的大多數專案都是基於行業應用的，行業應用的產品通常都有自己的引數指標，例如工控產品需要過竟EMC檢測等。

       另外公司也可以形成自己的普通軟體的測試標準，比如說，介面測試必須自動化測試1000次以上不失敗等。對於很多軟體而言，通過壓力測試也是必須的，例如高效能伺服器必須通過5000連線同時傳輸7天的壓力測試等。

       就此種種、建議大部分有勢力的公司在實施標準化和流水線作業模型的過程中，建立標準化、自動化、壓力測試部門，這些部門主要用於制定標準測試方案、流程和編寫自動化測試軟體。

       以上就是我的一些想法，似有不足，請大家評論。最後要說一句，印度的大部分外包軟體公司都成功實施了這種標準化和流水化的開發模式，其開發規模和效率確實遠高於我國。