構建之法第四章《**規範》
**規範分為**風格規範和**設計規範。其中**的縮排用四個空格，行寬可以限定為100個字元，括號表示邏輯優先順序和每個「」都獨佔一行等都是**風格的部分，這些運用的好會讓**顯得美觀，讓人不會一看**就「瘋」掉；而關於**設計則涉及函式、引數、類等的設計，當你的函式分類明確，引數設定讓人一看就能懂這是用來做什麼的，這樣的**就會顯得有層次、有條理。
**複審：看**是否在「**規範」的框架內正確地解決了問題。它的形式有：自我複審、同伴複審、團隊複審。
關於結對程式設計，其好處是：
（1）在開發層次，結對程式設計能提供更好的設計質量和**質量，兩個人合作解決問題的能力更強。
（2）對開發人員自身來說，結對工作能帶來更多的信心，高質量的產能能帶來更高的滿足感。
（3）在企業管理層次上，結對能更有效地交流，相互學習和傳遞經驗、分享知識，能更好地應對人員流動。
兩個人合作階段包括：萌芽階段、磨合階段、規範階段、創造階段和解體階段。
在每乙個階段中，兩個人一起合作，自然會出現不同的意見，沒有絕對正確或錯誤的方法，只有合適或不合適的方法，要學會聆聽別人對自己寫的**提出的意見，整合起來，找出更好地方法。
個人感悟：
1、我過去是怎麼做的：
不注意**規範，不注重縮排等**的排版問題
2、結合書中所講，說明為什麼不好
如果不注重**規範，後來程式出錯時會增大自己的工作量，同時，也增大了別人理解程式的難度。
3、提出乙個方法，避免再次掉入陷阱。
不論是用記事本還是用i編譯器編寫**，都要時刻注重**規範。
構建之法閱讀筆記03
通過這幾天的閱讀，基本對本書又有了新的認識，讀完這本書是一回事，要想深入的理解又是另一回事。本書第一版出自2014年，當時軟體工程正在中國蓬勃發展，在此書出來之前大學裡的教材有些還是外國書籍的翻譯版本。豆瓣上對此書的介紹是 軟體工程牽涉的範圍很廣,同時也是一般院校的同學反映比較空洞乏味的課程。但是軟...
構建之法閱讀筆記03
今天自己又回過頭來詳細的閱讀了一遍 構建之法 的第二章，下面分享一下自己的體會。一.單元測試 之前自己在程式設計的過程中，從來沒有對自己的程式進行過單元測試，總覺得輸出了題目要求的結果就行了，沒有考慮過程式執行的中間過程或是對占有的記憶體進行釋放等問題。而書中詳細介紹了單元測試的重要性和如何進行單元...
構建之法閱讀筆記03
又到了一周的結尾，時間過得真快。這一周，閱讀了 構建之法 關於團隊和流程的部分。正好，這周我們用的就是結對開發的模式。算是理論加上實踐吧。和以往的單獨程式設計不同的是，團隊開發增加了與同學的交流討論，在問題的解決與實現方面不再是一人單扛，可以交換不同的思路，用不同的角度思考問題，把問題更好的解決。這...