閱讀《構建之法》第四章、第十七章收獲
閱讀《構建之法》第四章、第十七章
閱讀這一章的時候，我意識到了很多以前寫程序沒有註意到的地方，以前寫程序就只知道能運行就好，根本不管自己寫的程序占多少內存，運行的時間，是否有優化的空間，寫代碼的時候也不註意規範，有時候設計的函數根本用不上，造成代碼冗余。同時也認識到結對編程的重要性，沒讀這本書之前就覺得結對編程就是兩個人一人負責一個模塊，然後合在一起，調試調試。但實則不然，真正的結對編程應該像書中那樣，一個是駕駛人，一個是領航人，兩個人有規律的進行編程。期間，一人編程一人復審，極大地提高了效率和編程水平。
第四章
原文：在C語言家族中，比較通用的，也是經過了很多實踐檢驗的方法叫“匈牙利命名法”。例如：
fFileExist，表明是一個bool值，表示文件存在；
szPath，表明是一個以0結束的字符串，表示一個路徑。
問題一：以前有的學長學姐給我們開討論班的時候一般會提到駝峰命名法，所以對駝峰命名法比較熟悉看書上可能有點沒太看懂“匈牙利命名法”的命名規則是什麽？
回答：在網上找了幾篇博客了解了一下，感覺有了點收獲。
http://blog.sina.com.cn/s/blog_810c86000101at9g.html
https://blog.csdn.net/haiross/article/details/45147993
https://blog.csdn.net/andrewniu/article/details/50477050
命名規則：變量名=變量類型+變量的英文意思（或縮寫）
開頭字母用變量的類型，其余部分用變量的英文意思或其英文意思的縮寫，盡量避免用中文的拼音，要求單詞的第一個字母大寫。
例如：1.指針變量命名的基本原則為：“p”+變量類型前綴+命名
2. 全局變量用 g_ 開頭,即：變量名=g_+ 變量類型+變量的英文意思（或縮寫）如：int g_nCount=0;
3. 靜態變量用s_ 開頭, 即：變量名=s_+變量類型+變量的英文意思（或縮寫）如：static int s_nCount;
4. 成員變量用 m_開頭,即：變量名=m_+變量類型+變量的英文意思（或縮寫）如：int m_nLineCount;
5. 對const的變量要求在變量的命名規則前加入 c_,即：c_+變量命名規則 如：const char* c_szFileName;
原文：
斷言
如何驗證正確性？那就要用斷言（Assert）。斷言和錯誤處理是什麽關系？
當你覺得某事肯定如何時，就可以用斷言。
Assert（p！=NULL）；
然後可以直接使用變量p。
如果你認為某事可能會發生，這時就要寫代碼來處理可能發生的錯誤情況。如.........
問題二：什麽是斷言？斷言與異常有什麽區別？
通過百度我了解到斷言是用來檢驗非法情況的。用錯誤處理代碼來處理預期會發生的狀況，用斷言來處理絕不應該發生的狀況。斷言通常用於調試版本，用來發現程序中的邏輯錯誤。
雖然看了幾篇博客，但是感覺對於斷言和異常理解的仍然不是很透徹。
原文：如何處理C++中的類
虛函數
（1）使用虛函數來實現多態。
（2）僅在很有必要時，才使用虛函數。
（3）如果一個類型要實現多態，在基類中的析構函數應該是虛函數。
析構函數
（1）把所有的清理工作都放在析構函數中。如果有些資源在析構函數之前就釋放了，記住要重置這些成員為0或NULL。
（2）析構函數也不應該出錯。
問題三：虛函數、析構函數是什麽？該如何使用？C++中的多態和Java中的多態有區別嗎？
虛函數
一個類函數的調用並不是在編譯時刻被確定的，而是在運行時刻被確定的。由於編寫代碼的時候並不能確定被調用的是基類的函數還是哪個派生類的函數，所以被成為“虛”函數。虛函數只能借助於指針或者引用來達到多態的效果。
析構函數的作用是用來完成對象被刪除前的一些清理工作，也就是專門的掃尾工作。
析構函數與構造函數的作用正好相反，如果構造函數打開了一個文件，最後不需要使用時文件就要被關閉。析構函數允許類自動完成類似清理工作，不必調用其他成員函數。析構函數也是特殊的類成員函數。
Java中的多態的三個條件是繼承、多態和父類引用指向子類對象。而C++中，如果父類中的函數前邊標有virtual，才顯現出多態。讀了一篇博客分享給大家。
https://www.cnblogs.com/plmnko/archive/2010/10/19/1855760.html
第十七章
原文：軟件團隊如何做人員的效績管理？有人說用工作量來衡量、有人說按照角色來定位、有人說根據工作時間來衡量。但是在軟件團隊中，不合理的效績考核不但影響個人的收入，而且會影響人員的士氣、流動、後續的合作以及產品的質量，不能不慎重。
問題四：如何進行效績考核才是最深入人心的呢？
我的看法：我覺得效績考核首先應該考慮的是團隊貢獻維度，在一個團隊項目中，你不是為自己做了多少，而是為了一個團隊付出了多少，是否有積極帶動團隊中的人員更加高效的工作，是否對團隊有正面影響，可以通過團隊成員進行投票選擇。其次，我覺得應該考慮個人的效率及其對產品的貢獻，個人效率體現出這個人時候將精力投放到項目中，如果將大部分的精力都放在項目中，那麽他的代碼質量會很高，測試人員能夠減少一些調試時間，會積極促進項目的開發速度。我們所希望的最好的團隊就是大家都能全身心的投入到工作中去，身邊的人互相影響、積極帶動，一起DeBug！
閱讀《構建之法》第四章、第十七章收獲