《構建之法》，讀這本書教會了我在團隊開發時的團隊合作。
首先是**規範：1.**風格規範。 2.**設計規範。
一.**風格規範
1.縮排：一般用四個空格的距離，從可讀性來說正好。
2.行寬：行款可以限定為100字元。
3.斷行與空白的{}行：盡量
if(a)else
4.分行：不要把多條語句放在第一行。
5.命名：在變數名中不要提到型別或其他語法方面的描述；避免過多描述；避免過多的修飾詞。
6.下劃線：可以用來標註。
7.大小寫：型別/函式/類的命名為大寫字母開頭，變數命名可以第乙個字母小寫，隨後單詞第乙個字母大寫。
8.注釋：好好寫注釋，因為程式不是你再寄乙個人看的，你的團隊其他成員也要看。
二.**設計規範
1.**有沒有依賴某一平台，是否影響移植。
2.有沒有無用的**可以清除。
下學期，我們要組成團進行開發，那麼，關於團隊模式，我更希望我們的團隊模式為社群模式，可以根據興趣去完成不同的模組，而不是明星模式，乙個人的閃光點蓋住其他人，我們應該要每個人都發揮各自的長處，更不要官僚模式，否則會造成不可磨滅的後果。同時，也希望在開發中運用上這些**格式，切記團隊合作不是乙個人在開發，有什麼問題要及時溝通，要多溝通，這樣問題才能乙個乙個地解決，希望下學期能學有所成。
這就是我今天的讀書筆記，獲益良多。
構建之法讀書筆記（三）
project manager 專案經理乙個神秘的角色，他就是夾在銷售人員與程式設計師之間的溝通媒介，銷售人員的方式程式設計師理解不了，程式設計師只想安安靜靜的敲 因此就出現乙個角色 專案經理，負責的就是將銷售人員的方式轉換為程式設計師可以理解的形式，這樣開發的效率就會大大的提高，同時專案經理不僅僅...
構建之法讀書筆記三
在做專案開發上，團隊協作尤為重要。之前也說過 需求分析 的問題，但在讀書過程中我發現了乙個問題，假如使用者方出現了需求更改，或者在原有的基礎上新增了乙個棘手的需求，導致工作變更怎麼辦？回答還是協商。坦白說看到現在我能用兩個詞概況軟體工程要幹的事情 開發與溝通。但要是跟使用者協商溝通，雖然能達到乙個妥...
構建之法 讀書筆記三
現在已經讀完這本書了，感覺自己又充實了。首先了解了敏捷開發的基本原則 1.盡早並持續地交付有價值的軟體以滿足顧客需求。2.歡迎需求的變化 3.經常發布可用的軟體，間隔時間盡可能的短 4.團隊每天共同工作 5.以有進取心的人為專案核心 6.面對面的交流 7.發布可用的軟體 8.領導 團隊和使用者應該能...