在這一周裡我閱讀了建構之法中的軟體工程師的成長和軟體單元測試與代碼規範。這兩部分對我來說還是有較多的感觸的，當然也有不少的收獲。
很喜歡建構之法這本書，一下子改變了我對軟體編寫的态度。也許是因為以前并沒有接觸過這種教學模式，也許是這本書把枯燥乏味的軟體實際化了，使我慢慢的開始去程式設計。我從未想過一個軟體工程師的成長會有這麼多的經曆，總以為語言類的東西是一種天賦，也總認為隻要你編寫了足夠多的程式就可以成為頂尖優秀的工程師。我喜歡看籃球比賽，在書中，他舉了程式員與NBA籃球的例子，一下子吸引了我，那些資料我清楚的知道對一個籃球運動員意味着什麼，但是我從未想過一個程式員也可以通過各項資料來反映一個程式員的技術。
通過學習軟體單元測試與代碼規範，我現在還不能很好的了解單元測試的意思，但是我卻想到了國小期時，我們編寫資料結構多個人往一起合并程式時，總是出現錯誤，單個運作沒有問題。我想這個跟我們的單元測試有問題吧，尤其是遇到比較大的項目開發時，更會引發諸多Bug，看來單元測試極對于團隊開發極其重要。代碼規範也給我好好的上了一節課，受益匪淺。
個人體會：由于以前并沒有很多的運用軟體單元測試，因而對這部分還不是很了解，也沒有過多的體會，唯一記着的也就是國小期合并程式時出現的Bug。但是對代碼規範真的是感受頗深。
1、在以前很少會注重代碼格式問題，也沒有注意到程式的結構和子產品問題（因為程式設計少，能百度就百度了），甚至注釋部分也不怎麼寫，代碼命名部分逮住哪個字母單詞就随便亂用一通。結果很多情況下就算自己編寫出來了，自己都不知道什麼意思。
2、學習代碼規範後，明白了一個道理，自己能編寫程式，自己能看懂沒什麼了不起，當别人能看着你的程式很舒服時，也願意看時才是好程式。程式講究：簡明，易讀，無二義性。而我的程式，不太好閱讀，注釋部分沒有，定義的自變量沒有清楚地訓示，大小寫也沒注意到，自己看着确實很難看。哎
3、為了解決以上這些問題，我想從現在開始去改變自己的換習慣，不能隻是圖友善，更要注重細節，易讀，簡明，沒有歧義。一、注釋部分要明确，必要的地方解釋清楚。二、一條語句為一行，絕不多行同時擠到一行。三、代碼要有縮進，比如if和else要有明确的關系。四、代碼中如果需要定義的自變量，盡量按其英文來命名（複雜情況下）。五、括号關系要十分明确，小括号，中括号，大括号。目前先給自己提出這幾點要求，争取改變，使程式更為被人接受。