構建之法讀書筆記
沈三景pb15061249軟體工程讀書筆記
本週閱讀了構建之法的
四、五兩個個章節。這三個章節主要講述了**規範、結對程式設計、團隊模式、開發流程。
首先提到的是**規範，程式設計師寫的**不僅要給機器看，還要給人看。好的**規範能事半功倍。**規範有分為**風格規範和**設計規範。**風格規範是指讓**保持簡明，讓**更易讀。書中給出的規範是tab鍵為4個空格，行寬為100字元，在複雜的表示式中要用括號來表示邏輯優先順序，斷行和{}最好為：
if(condition)
else
即單獨成一行，注釋要表明程式做什麼？為什麼這樣做？對於**設計規範，乙個函式只做一件事，且要做好，函式要有單一的出口，僅在必要時才用類。
其次講到的是**複審，**複審的目的是為了發現各類錯誤，以及可以改進的地方。
最後提到的是結對程式設計。結對程式設計是指一對程式設計師平等的併發進行開發工作，即用同乙個顯示器，同乙個鍵盤，同乙個滑鼠工作，一起分析，一起編碼，一起測試。這樣子帶來的好處是能提供更好的**質量，給程式設計人員帶來更多的信心，已經增進交流，相互學習。
在本章中首先提出的乙個問題是什麼是團隊？是七八個人聚在一起就是團隊嗎？不一定，也許他們只是一群烏合之眾。乙個團隊，需要有乙個明確的集體目標，並且團隊成員要一起完成這個目標，這些團隊成員有各自的分工，相互依賴合作，共同完成任務。這樣的一群人才能稱之為乙個團隊。
團隊有很多模式，比如：主治醫師模式、明星模式、社群模式、業餘劇團模式、秘密團隊模式、**團隊等等這些模式有各自的優缺點，但可以肯定的是很多團隊最終都會演變成功能團隊，即具有不同能力的同事平等合作，共同完成乙個功能，在這個功能完成之後，這些人又重新組織，和別的角色一起完成下乙個功能。他們沒有管理者和被管理者的身份關係。
作者在本章還介紹了團隊開發的流程，讓我感興趣的是漸進互動流程。在這個流程中，軟體團隊進入了乙個不斷演進的evolution迴圈中：開發-->發布-->聽取反饋-->根據反饋做改進。直到錢花完了，時間到了，使用者滿意了為止。這個模式有乙個最大的問題，就是如果使用者對第乙個版本不滿意，不想購買產品，那麼整個團隊為第一版所做的努力都白費了。這個問題的根源是團隊得到客戶的反饋太晚了，對此作出的改進是，把產品的最核心功能用最小的成本開發出來，然後快速聽取客戶的意見。
構建之法讀書筆記二
在學習這麼多之後，軟體工程給我的印象是 使用者需求的框架 樸實 的填充。那麼在寫軟體的時候一定要用傻瓜式的 了麼？顯然不是，高階演算法能極大地減少時間複雜度與空間複雜度，只是放在大型工程裡，需要注意資料與其他模組的關聯性。現在我們先討論什麼是 好軟體 一般情況下我們認為沒有bug的軟體就是乙個好軟體...
構建之法 讀書筆記二
現在這本書已經讀了有三分之二了，看到這，我大概了解了關於個人技能提公升和團隊協作的知識。關於個人的成長，肯定是在不斷地實踐，不斷地出差錯，不斷地改進 解決問題 總結經驗中體現的，然後成為自己的知識，這就是提公升。而在軟體工程上也一樣，提公升不僅僅是在技術的提公升，更是在知識的積累，軟體設計思想的積累...
《構建之法》讀書筆記二
繼上次之後，讀了 本書的7到12章 下面主要寫一下書中覺得重要的東西。msf基本原則。1.推動資訊共享與溝通。2.為共同的遠景而工作。3.充分授權和信任。4.各司其職，對專案共同負責。5.交付增量的價值。6.保持敏捷，預期和適應變化。7.投資質量。8.學習所有的經驗。9.與顧客合作。對軟體的需求，也...