構建之法 第四、五章心得

學習了第四第五章之后，我了解到了兩人合作的注意要點，還有團隊和開發流程。軟件都是在相互合作中完成的，合作的最小單位是兩個人。每個人的標準都不一樣，對于什么是好的代碼規范未必認同，所以我們需要給出一個基準線，即什么是好的代碼規范和設計規范。

代碼規范可以分成兩個部分，一是代表風格規范，主要是文字上的規定，看似是表面文章，實際上非常重要。二是代碼設計規范，牽涉到程序設計、模塊之間的關系、設計模式等方方面面的通用原則。代碼風格的原則是：簡明、易讀、無二義性。這里可以從幾個方面來闡述代碼風格規范。

1.縮進，在寫代碼時，4個空格的距離正好。

2.行寬，行寬必須限制，現在可以限定為100字符

3.括號，在復雜的條件表達式中，用括號可以清晰地表示邏輯優先級

4.斷行與空白的{ }行，這樣可以很容易看清結構和對應關系

5.分行，寫代碼時，不要把多個變量定義在一行上

6.命名，在變量面前加上有意義的前綴，程序員就能一眼看出變量的類型及相應的語義

7.下劃線，下劃線用來分隔變量名字中的作用域標注和變量的語義

8.大小寫，便于區分由多個單詞組成的變量名

9.注釋，有了注釋，才能解釋程序做什么，為什么這么做，以及要特別注意的地方。

對于程序的錯誤處理，有參數處理和斷言兩種，所有的參數都要驗證其正確性。對于C++中的類有以下幾種處理方法：類，class vs.struct，公共/保護/私有成員，數據成員，虛函數，構造函數，析構函數，new和delete，運算符，異常，類型繼承。

除了代碼規范，我們還要進行代碼復審。代碼復審是看代碼是否在“代碼規范”的框架內正確的解決問題。在軟件工程中，最基本的復審手段，就是同伴復審。代碼復審可以找出代碼的錯誤，或者說一些不符合 團隊代碼規范的地方，也可以讓更多的成員熟悉項目各部分的代碼，同時熟悉和應用領域相關的實際知識。如果我們不開發實際的軟件，就只能在表面上完全掌握，所以要在實踐中學習。

要注意避免不必要的繁文縟節，因為我們做代碼復審的目的是為了減少錯誤的發生。我們還需要一個代碼復審的核查表，在實際項目中，我們可以加上自己認為重要的注意事項：概要部分、設計規范部分、代碼規范部分、具體代碼部分、效能、可讀性、可測試性。雖然代碼復審很好，但是我們還是應該進行結對編程。在結對編程中，因為有隨時的復審和交流，程序各方面的質量取決于一對程序員各方面水平較好的那一位。

軟件團隊有很多種形式，適合不同的人員和需求。有主治醫師模式、明星模式、社區模式、業余劇團模式、秘密團隊、特工團隊、交響樂團模式、爵士樂模式、功能團隊模式、官僚模式。不同的團隊應根據團隊本身選擇各自的團隊模式。

從瀑布模型開始的各種模型都有一個特點：重計劃、重事先設計、重文檔表達。RUP把軟件開發的各個階段整合在一個統一的框架里。要完成一個復雜的軟件項目，團隊的各種成員要在不同階段做不同的事情，這些不同類型的工作在RUP中叫做規程或者工作流。不同的軟件設計有不同的流程，如RUP統一流程，老板驅動的流程，漸進交付的流程。

在團隊合作中，我們都應該清楚的了解自己的定位，做好自己的本職工作，并且盡力配合團隊中其他成員，一起完成設計。

轉載于:https://www.cnblogs.com/hxy-/p/6771606.html

總結

以上是生活随笔為你收集整理的构建之法 第三次心得的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。