第四章讀後感

在經過對第四章的閱讀後，我更加清晰地認識到了在項目開發中，規範二字的重要性，也新學到了除開代碼規範以外，其他對於團隊協作也很重要的東西，比如說構造函數的使用，模塊化的編程思想，當然自己也對一些問題有著自己的思考。

其中最大的疑惑就是在於我個人對結對項目的理解上了，在經歷過個人項目以後，我深刻地意識到模塊化編程的重要性，因其能在很大程度上降低代碼的冗雜程度，改善代碼的可維護性，就像書中所說的：關於函數，最重要的原則就是只做一件事。所以我對於結對項目的理解就是：兩人在相互商量以後，確定項目的大框架，包括項目下所需要的類、方法，然後進行分工，分別完成不同類的編寫，最後就像拼樂高積木一樣，將各自構造的零件平湊到一塊。這種默認情況下自己對於結對項目的理解一直持續到了第四章快看到一半，直到看到書中所寫“一對程序員肩並肩、平等地、互補地進行開發工作……”然後想法就完全被顛覆了，雖然是出於極限復審的角度來進行這種模式的結對編碼，但是各自編寫不同的類，方法，然後再復審不也是一樣能很好的去審核麽？更何況這種模式能極大程度上將兩個人的作用同時發揮到極致，而書中的結對模式會讓人有一種“1+1最多等於1.5”的感覺。

第二個疑惑其實也算是依附在第一個疑惑裏面了，書中在說極限編程的時候提到了這樣一句話“如果我們時時刻刻都處在代碼復審的狀態，那不是更好麽？”首先，代碼是一個一行一行敲下來的東西，不像人的思想，能夠有一個大的框架，時時刻刻復審的極限編碼就像是在別人在寫文章，明明應該是看一個段落所要表述的意思、把握段落在文章中的作用，但是審核的落腳點卻只停留在他每句話有沒有語義通順，字有沒有寫錯，類似這種情況，所以在一個個零件編寫完之後逐個地對方法、類進行審核不是更好麽？

構建之法第四章讀後感