《構建之法》讀後感

        開篇講到一個概念即：軟件=程序+軟件工程。

        書中說到，程序指的是源程序，也就是基於數據結構上的實現算法，這是咱們軟件學生的基本功。程序員須要對代碼不斷編寫，程序愈來愈龐大，就須要源代碼管理。程序是要正確運行的，就須要軟件測試。咱們寫的程序須要讓別人的看得懂，就得運用程序理解。程序總會出現BUG，就須要軟件維護。掌握一系列過程須要一個項目經理，稱爲項目管理。

        因此，構建管理（數據結構+算法），源代碼管理，軟件測試，軟件維護，項目管理，需求分析這些環節構成了軟件工程。

        咱們在學校作一些小項目的時候，每每沒有用到軟件工程去進行開發，運營，維護。甚至有的不通過需求分析，就一邊打代碼一邊構造需求，軟件工程是把系統的，有序的，可量化的方法應用到軟件的開發，運營，維護過程當中。

       

       我的技術和流程

        如今的開發每每是不少人合做完成一款軟件應用，不一樣的開發人員之間就存在依賴關係。我須要調用你寫的代碼模塊，你也須要調用我寫的代碼模塊，可是由於不瞭解模塊的變化，模塊沒有達到高內聚低耦合形成了對其餘模塊的影響，每每會產生錯誤。在肯定發佈這個模塊的時候，要通過完整的單元測試，爲了達到事半功倍的效果，咱們能夠把規格說明說寫得詳細一些，詳細到各項要求均可以表示爲一個單元測試用例。

       卡耐基梅隆有一套我的開發流程，很適用於咱們作我的開發。接到項目以後咱們能夠按照如下幾個步驟來進行，

       估算時間--->需求分析--->生成設計文檔--->設計複審--->代碼規範--->具體設計--->編寫代碼--->代碼複審--->代碼測試--->記錄用時--->測試報告--->計算工做量--->總結--->討論改進。隨着工做年限的增加，編碼所佔的比例會愈來愈小，由於開發再也不是一味地編碼，測試所佔的比重會愈來愈高，保證質量要求。

 

       軟件工程師的成長

       那麼，咱們爲何要用軟件工程呢？由於軟件工程把開發，運營，維護的過程當中的技術，作法，習慣和思想結合到一塊兒（軟件開發流程）提升了軟件開發，運營，維護的效率。同時，運用軟件工程，也減輕了咱們的工做量，避免沒必要要的返工。

      怎麼提升技能？經過不斷的努力，把那些低層次的問題都解決了，變成不用通過大腦的自動操做，而後纔有時間和腦力來解決較高層次的問題。咱們要精通低層次問題(int[] arr仍是int arr[],ArrayList 仍是 Array<T>),中層次問題（使用何種架構),高層次問題(效能優化。。。。。。).

 

      兩人合做

      如今的開發已經不多是單獨完成的，最少也是兩我的了。咱們寫代碼不只僅要讓機器瞭解，更要讓別人看得懂，讓你的隊友看得懂。這就須要代碼規範。代碼規範分爲代碼風格規範和代碼設計規範。代碼風格規範包括：縮進，行寬，{}的位置，分行，命名，大小寫。其中我認爲比較重要的有：每一個語句只定義一個變量，作一個操做。即使IF和ELSE語句只有一句，也使用{}。在變量名中加入下劃線表示做用域，如m_iAge。

       代碼設計規範不光是程序書寫的問題了，並且牽涉到程序設計，模塊之間的關係，設計模式等等。

       一個函數只作一件事。

       按照public,protected,private順序來講明類中的成員。

       在小型軟件開發過程當中，有一種模式叫作結對編程，在這種模式下，一對程序員一塊兒完成設計，代碼，測試，文檔工做，因爲每一個工做都被兩雙眼睛看過，程序的初始質量取決於各方面水平較高的那一位程序員，在整個開發過程當中不斷地進行着潛移默化的複審。

 

       團隊和流程

        什麼是團隊？團隊有一致的集體目標，團隊要一塊兒完成這個目標。團隊成員有各自的分工，互相依賴合做，共同完成任務。剛開始創業時，一些程序員聚在一塊兒想寫出好的程序，一擁而上一塊兒解決問題，這是最簡單的模式（一窩蜂模式）。逐漸地，團隊就會過渡到如下模式。

        主治醫師模式：有一位首席程序員，負責處理主要模塊的設計和編碼，其餘成員從各類角度支持他的工做。

        社區模式：有一些志願者參與本身感興趣的項目，不拿報酬，如linux社區。

        業餘劇團模式：這樣的團隊在每個項目中，不一樣的人會挑不一樣的角色。在下一個項目中，這些人也許會完成換成另一個角色。團隊有個老大指揮一切。

        功能團隊模式：具有不一樣能力的同事們平等協做，共同完成一個功能。

        一塊兒作軟件，總要有一些開發方法，好比：

        謝了再改模式：不須要太多的知識，直接上手寫代碼，一直改，直到發佈。

        瀑布模型：單向不可逆，最終產品直到最後纔出來。按照需求分析-編碼測試-發佈一步步走下來。力求一次完成。

        RUP統一過程：在大的尺度上像瀑布模型，在每一個階段內像迭代模型。初始階段：分析系統大概的構成，和什麼樣的外部實體打交道，大體的成本和預算是多少。細化階段：編制項目計劃，確認主要的功能，性能。構造階段：把全部的功能集測試併發布爲Beta版。交付階段：基於用戶的反饋，不斷進行修改。