粗略的看了一遍構建之法，其實感觸還蠻多。這本書為我看待這個行業開啟了乙個新視角。
其實關於團隊合作方面，我自己是深有感觸。從乙個比較小的方面來講就是我們對於別人的**通常都是沒有耐心的，這裡有兩個方面的沒耐心：一是當兩個人在做相似功能的東西時，我們通常有自己的思維，並且能夠完成，但是當別人在完成時出了點小岔子，問你是怎麼做出來的時候，我們通常是轉頭一看，傻傻看不懂，完全沒耐心理解別人的邏輯，並且按照別人的邏輯來改。二是如果我們需要上乙個人**中的資訊通常是直接問你的xx是什麼，xx在**之類的。能有明確的答覆還好，如果沒有的話就感覺雙方都很焦慮，都在想你為什麼不是這樣之類的話。其實這樣經常讓乙個團隊的氛圍在不知不覺之內陷入有點尷尬緊張的地步，雖然不至於毀天滅地一拍兩散但是合作之後下次合作也會猶豫猶豫。
所以從實際角度上來講，對別人**的耐心通常是很難做到的，尤其是自己有自己的**來解決同樣的問題時。
我想我第乙個消除別人看不懂自己**的行動就是要規範**。書中對**規範提到兩點：一是**風格規範，二是**設計規範。從我的角度來看，規範風格設計這點還是比較容易的，因為一開始學習老師就有強調程式格式，平時只要注意別太擠是沒有什麼大問題。但是對於設計的規範就差很多，不是每個人對規範的理解都相同，況且我們自己獨立完成**時也經常忽略這方面的鍛鍊，書中4.3部分講的還是很實際的，所以我認為多看看書本附帶長**，再加上4.3的那些東西在腦子裡有個印象，應該能夠改善不少。
第二就是盡量留下一點文字材料和注釋，方便別人理解你的**這些部分都是幹什麼的，方便後來者接受。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...