構建之法讀書筆記

構建之法讀書筆記

沈三景 PB15061249 軟件工程 讀書筆記

前言

本周閱讀了構建之法的四、五兩個個章節。這三個章節主要講述了代碼規範、結對編程、團隊模式、開發流程。

第四章 兩人合作

首先提到的是代碼規範，程序員寫的代碼不僅要給機器看，還要給人看。好的代碼規範能事半功倍。代碼規範有分為代碼風格規範和代碼設計規範。代碼風格規範是指讓代碼保持簡明，讓代碼更易讀。書中給出的規範是Tab鍵為4個空格，行寬為100字符，在復雜的表達式中要用括號來表示邏輯優先級，斷行和{}最好為：
if(condition)
{
Dosomething();
}
else
{
Dosomethingelse();
}
即{與}單獨成一行，註釋要表明程序做什麽？為什麽這樣做？對於代碼設計規範，一個函數只做一件事，且要做好，函數要有單一的出口，僅在必要時才用類。

其次講到的是代碼復審，代碼復審的目的是為了發現各類錯誤，以及可以改進的地方。

最後提到的是結對編程。結對編程是指一對程序員平等的並發進行開發工作，即用同一個顯示器，同一個鍵盤，同一個鼠標工作，一起分析，一起編碼，一起測試。這樣子帶來的好處是能提供更好的代碼質量，給編程人員帶來更多的信心，已經增進交流，相互學習。

第五章 團隊合作和流程

在本章中首先提出的一個問題是什麽是團隊？是七八個人聚在一起就是團隊嗎？不一定，也許他們只是一群烏合之眾。一個團隊，需要有一個明確的集體目標，並且團隊成員要一起完成這個目標，這些團隊成員有各自的分工，相互依賴合作，共同完成任務。這樣的一群人才能稱之為一個團隊。
團隊有很多模式，比如：主治醫師模式、明星模式、社區模式、業余劇團模式、秘密團隊模式、特工團隊等等這些模式有各自的優缺點，但可以肯定的是很多團隊最終都會演變成功能團隊，即具有不同能力的同事平等合作，共同完成一個功能，在這個功能完成之後，這些人又重新組織，和別的角色一起完成下一個功能。他們沒有管理者和被管理者的身份關系。

作者在本章還介紹了團隊開發的流程，讓我感興趣的是漸進交互流程。在這個流程中，軟件團隊進入了一個不斷演進的evolution循環中：開發-->發布-->聽取反饋-->根據反饋做改進。直到錢花完了，時間到了，用戶滿意了為止。這個模式有一個最大的問題，就是如果用戶對第一個版本不滿意，不想購買產品，那麽整個團隊為第一版所做的努力都白費了。這個問題的根源是團隊得到客戶的反饋太晚了，對此作出的改進是，把產品的最核心功能用最小的成本開發出來，然後快速聽取客戶的意見。

第二周讀書筆記《構建之法》