軟件開發的專業化

    以前的文章中，說起軟件開發專業化。今天來簡單概況下專業化，主要有以下的幾個方面：

1.統一編碼規範

   一般是Coding Guideline(編碼標準)，包括註釋，變量，方法名，命名規則。編碼標準在好處在於80%的時間裏，代碼都不是初始編寫者來維護或擴展的，僅這一點就足以說明編碼標物業從一開始就具有的經濟優點。不可維護的代碼比其餘任何事情都會更快地消耗開發人員的精力。

2.注重軟件質量

   高內聚，低耦合，低冗餘，可測試性，可讀性，測試。

  

   內聚是系統內部的各個部分對同一個問題的專一程度，以及這些部分彼此聯繫的緊密性。用來衡量對目標的專一度或專注性的標準，而且使得實體(類，方法)的命名和理解變得更容易。涉及到方法，類，包，應用程序，系統，解決方案的內聚。

   耦合用於描述系統某一部分以某種方式影響系統另外一部分的狀況。在OOP面向對象編程中，咱們指的是兩個類，當其中一個與另外一個耦合時，第二個類中的變化會使第一個類也發生變化(或須要發生變化)。

  

   質量反映在代碼中，一切工做最後都歸結爲代碼。

   不得不去處理變動需求是件使人頭痛的事情，可是若是代碼清晰可讀，若是解耦使得代碼更易擴展，內聚性強，能夠輕鬆肯定系統中必須修改的部分，代碼沒有冗餘，每一個修改只需在一個地方進行，那麼處理變動請求就會容易得多。

   開發高質量代碼最終並無要求你付出更多，只是你須要對資源進行從新分配，以低廉的成原本防止缺陷出現，從而避免代價高昂的修正工做。

   計劃測試，測試用例，單元測試,集成測試,確認測試,系統測試,驗收測試,迴歸測試,Alpha測試,Beta測試等。而自動化測試發生錯誤的機率比手動測試要小。程序測試的過程具備破壞性,程序員應避免測試本身的程序,程序設計組織不該測試本身的程序。

3. 注重原則與智慧結晶 
   

    S.O.L.I.D, DIY(Don’t repeat yourself),KISS, GRASP (object-oriented design)，YAGNI， Separation of concern(分散關注), Design Patterns(設計模式)，DDD(Domain-driven design)領域驅動設計等這些都是前人總結出來原則與模式。模式自己並非它們之因此重要的緣由，咱們之因此有必要知道模式是由於它們可以幫助咱們作出優秀的設計，可以幫助咱們與同行進行更高層次的溝通，它還爲咱們提供了一種途徑，令人們可以採集咱們對某些特殊的，反覆出現的開發場景已經掌握的知識。

4. Code Review(代碼複查), Code Inspection(代碼審查)， Walk-through(走查)

    優秀的CodeReview工具可支持設置強制性，未經過Review的代碼沒法提交的正式的代碼庫。支持多人Review，標記，評論，相似郵件同樣的To,Cc到每一個人，與郵件服務緊密結合。甚至應用自動Code Review工具。

    代碼審查是最正規的審查會議。一個檢驗的惟一目的是爲了在文檔中發現缺陷。能夠用來檢查審閱計劃文檔，需求，設計或代碼，總之，產生在任何產品開發團隊。代碼審查甚至於具體的規則多少行代碼來一次審查，審查會議必須是多長時間，和審查小組的每一個成員應該作多少準備，在其餘的事情上。

    Walk-through會涉及兩個或者更多的人，進行設計或者代碼的相關討論，重點在於檢測錯誤，而非修正它們。

5. TDD測試驅動開發，BDD行爲驅動開發，結對編程, FDD(Feature-Driven Development)
   

    TDD確保重構可以達到所要求的測試覆蓋度，並且，當一個模式在設計中是否適用並非很明顯的時候，TDD能夠幫助咱們提升設計的質量。

    行爲驅動開發是測試驅動開發的進化，但關注的核心是設計。行爲驅動開發中，定義系統的行爲是主要工做，而對系統行爲的描述則變成了測試標準。在行爲驅動開發中，咱們須要使用通用語言來定義系統行爲。

    結對編程鼓勵雙方保持雙方保持代碼的高質量，結對可以令人們在壓力之下保持更好的狀態，能縮短進度時間表。

    FDD是以客戶、架構爲中心，迭代與演進的實用的軟件開發過程。它是敏捷軟件開發方法中一種。

6. 軟件設計原則與方法

    原則: 適於目的，簡單，分散關注，易於維護。方法: 抽象是關鍵，信息隱藏，發現現實世界中的對象，鑑定出可能出現的變化點，使用原則與模式在合適場景下，使用圖來作爲設計語言。

7. 持續集成(Continuous integration)

    實現的目標包括維護代碼庫，自動化編譯，保證快速編譯，便於提交最新發布，每一個人能看到最新構建結果，自動化部署。實現Daily Build與冒煙測試，與IDE(集成開發環境)集成在一塊兒的工具備助於團隊協助，例如微軟的Visual Studio Team Found Server，管理Project進度，燃盡圖。團隊信息共享站點，如SharePoint構建的文檔共享與Wiki,與OneNote等筆記工具整合。實現知識分享的工具，又如構建Bugs缺陷跟蹤管理系統。

8. 持續交付(Continuous delivery)
   

   自動化開發一切過程(構建，測試，部署，打包，發佈), 並把它們集成到版本控制系統。

   公司內部花費時間去設計構建這樣的自動化平臺，後期則能極大得高工做效率，最終也是標準，規範化。 例如，OneBox與虛擬化結合，最終構建一個盒子用於測試與發佈。自動化是部署流水線的前提條件。由於只有經過自動化，才能讓你們僅經過單擊一下按鈕就獲得他們所想要的。固然，你不須要把全部的東西一次性地所有自動化。在構建、部署、測試和發佈過程當中，哪一個環節是瓶頸。隨着時間的推移，最終能夠將全部環節所有自動化。經過採用自動構建、測試和部署技術，能夠得到不少益處，咱們將可以驗證變化，重現各類環境中的部署過程，在很大程度上減小產品出錯的機會。

    最終的目標一致：爲了更加快速且可靠地交付有價值的軟件，鼓勵全部參與軟件交付整個過程當中的人進來。

行更好的協做。

9. 重構（Refactoring）

   在今天IT信息化發展過程當中，一定存在對已有軟件維護開發狀況，這時還須要重構。重構就是在不改變軟件現有功能的基礎上，經過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提升軟件的擴展性和維護性。如今還演化出數據庫重構，如上面所示。

10. 系統架構文檔

專業的文檔應該描述：上下文，變化點，架構決策.

接口文檔，組織接口文檔，干係人接口文檔，用來傳達詞彙，語義信息。

行爲文檔，架構設計文檔。它們一般會使用到如下描述語言：
UML(Unified Modeling Language)
SysML(System Modeling Language)
AADL(The SAE architeture Analysis and Design Language)

 

    軟件開發領域還涉及需求分析，系統分析，架構設計，開發方法論，團隊管理，項目管理等體系的內容，在這裏未能都涉及。上面各個方面與軟件開發專業化與實踐點過而止，因爲篇幅有限未能展開描述，若有興趣能夠查詢相關資料。 

    但願對你軟件開發有幫助。

    您可能感興趣文章:

職場中僱主公司的狀況分析 

軟件架構中質量特性
企業服務總線Enterprise service bus介紹

做者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。
該文章也同時發佈在個人獨立博客中-Petter Liu Blog。