閱讀第四章、第五章所得：
首先提到的是**規範，上課的時候老師也提到了並且強調**的規範對於閱讀**的人或者是編寫**的人來說都是很重要的。**風格原則即簡明、易讀且無二義性。其中縮排（4個空格）、行寬（可限定為100字元）、括號、斷行與空白的{}行、分行、命名（匈牙利命名法或其他）、下劃線、大小寫和注釋等。**複審也是極其重要的部分，包括自我複審、同伴複審和團隊複審。而最基本的是同伴複審。開發中的複審主要包括：設計複審、**複審、測試計畫複審和文件複審。而程式設計也可以是結對程式設計，均為兩人合作的形式。好處在於，提供更好的設計質量和**質量、帶來更高的滿足感和更有效的交流。兩人合作也需要技巧。而交流也起到了一定的作用。
團隊就是有一致的集體目標、有各自的分工、互相依賴和共同完成任務。軟體團隊的模式包括主治醫師模式、明星模式、社群模式、業餘劇團模式、秘密團隊、**團隊、爵士樂模式、功能團隊模式和官僚模式。開發流程的形式包括寫了再改模式、瀑布模型等等。由此看來，團隊合作的形式和開發軟體的流程都是不盡相同的。
今天一下子閱讀了四章內容，中間還有點不理解的地方，也算是帶著問題上課啦。
個人感受：
1、我過去是怎麼做的（或者我過去看見誰是怎麼做的）；過去**的注釋還有**不是很規範。
2、結合書中所講，說明為什麼這樣不好:不有助於理解**。以後是要團隊合作的，對團隊他人無益處。
3. 提出乙個解決辦法，避免再次掉入陷阱：要盡量去注釋和遵守**規範。
構建之法閱讀筆記三
構建之法閱讀筆記之三 12 16章節 之前寫程式的時候從來沒想過使用者的體驗這一點，從來就是自己感覺怎麼簡單怎麼來，也沒有過多的想那麼多的問題，就是自己寫自己的，而且就是自己在寫 的時候很多就是跟著前人的腳步走，沒有過多的想法去創新什麼東西 看完這本書之後感覺自己差得很多，而且之前自己寫的也不是很合...
《構建之法》閱讀筆記三
在我們使用軟體的時候，我們總是因為對某個軟體有著某種需求才回去使用，那麼軟體團隊如何去了解和挖掘使用者對於軟體的需求，並且引導使用者表達出對軟體的需求。而如何獲取需求，有很多的辦法，我們最常見到的就是乙個公司上線了一款免費軟體來吸引使用者使用，同時在軟體上面設定了不少的使用者許可權來獲取使用者資訊，...
構建之法閱讀筆記三
這次閱讀筆記主要關於團隊和流程，課上也又詳細講過，這裡簡單複習下，該章節主要介紹了典型的軟體團隊模式和開發流程以及它們的優缺點 tsp mvp mbp rup 團隊的定義 玩的好的哥們組成乙個隊，他們可以稱之為乙個團隊嗎？1 應該有一致的集體目標，團隊要一起完成這目標 2 團隊成員有各自的分工，互相...