Book Review 《構建之法》

1. -首先瀏覽了一遍《構建之法》這本書的前言,其中通過客觀的描述性介紹了學生與學習、老師與教學、以及學習的環境、方法等等。但是對於書中前言包括正文都頻繁出現的一個詞語 “文件” 深表疑問.何為文件，是指帶程式碼？還是另有其他含義。
2. -接著看下去，第一章用前言的風格，闡述了軟體含義,軟體工程與電腦科學,Bug.對於軟體的階段性,個人理解來說就是軟體是要一步步來提升完善.由開始的感興趣到動手出成品再到完善維護這都是一步一步來進行的.軟體工程是為了某個特定的目的而專門建立的一個專案工程，所謂工程就有一定的層次性這一點也是跟程式開發是類似的具有階段性.書中也是提及電腦科學和軟體工程的側重點.前者就像是JAVA 中的主類，而後者是子類。 軟體工程 的進展會為 電腦科學 提供跟多的“資源”,幫助科學家做跟多的實驗探索。而電腦科學得進展會提高軟體工程的正確性.就像是父類對子類的一個完善，提升.子類對父類的一個反饋。最後是Bug這個詞,以前的理解就是系統出現的漏洞，不完善的地方,指代不好的東西、地方.而書中給出了另一種說法"Bug 就是軟體的行為和使用者的期望值不一樣.",沒有褒貶的意味。這個倒是有點出乎意料，但也是很生動的體現出程式的針對性.不合適就是不好 ！
3. -第二章的一開始就出現了”單元測試“.呵呵，這個正是上次作業老師給的一個建議。在看了第二章之後覺得對單元測試有了一個模糊的理解.沒有十分的清晰的概念，感覺就是增加模組去捕捉軟體執行出現的錯誤並給予提示。這裡希望老師可以指點下”單元測試“的具體意思- 。- 
4. -至於第三章關於軟體工程師的成長：在學習階段首先就是要對自己有一個全面提升，無論在專業技能，還是經驗、思想等。再在實踐中根據自己的情況選擇在哪個方面追求“專和精”，在那幾個方面達到“知道就好“的水平.來提高自己的核心競爭力。
5. -第四章兩人合作，一個團隊中需要有統一的程式碼風格。在結對程式設計的過程中要時刻進行復審.換句話說就是要自我複審、同伴複審、團隊複審。更正並且記錄下錯誤，進行一個自我的提升.無論結對還是團隊都是有一定的階段性的，並且都是可以提高程式總體的質量的。但是這都是有前提：“必須有一個團隊、結對”，那麼在進行結對也好團隊合作也罷前，豈不是要花費很多時間去找合適同伴，相互磨合.不然中途如果發生激烈的衝突導致解體的話就會對整個專案造成致命傷害了？
6. -在兩人合作之後就是團隊合作，在第五章中強調了團隊合作的各種模式：社群、業餘劇團、祕密團隊、特工團隊、交響樂團隊等等很多種模式，適合各種不同型別的專案，具備自己的優點短處。在書中強調出團隊之間隊員的關係與分工,還有就是專案的流程。一個團隊要想成功合作，那就離不開模式指引，而一個專案需要模型來引路。那麼一個團隊如何去確定一個合適的團隊模式呢？一個專案怎麼知道那種流程是最好的呢？