當我初次看到這本書的時候，就感覺厚厚的一本，並沒有什麼特別之處，甚至還有點讀不下去。隨著老師的講解，我對這本書有了更深刻的認識，結合自己的實際情況，有了更深刻的理解。
一，關於自己的**和閱讀別人的**
現代軟體產業經過幾十年的發展，乙個軟體有乙個人單槍匹馬完成，顯然是不太可能得了，由於現在的軟體體量大，功能複雜，俗話說「人多力量大」，現代的軟體都是在相互合作中完成的，所以閱讀別人的**必不可少。所以這裡邊就涉及到兩個問題：1.自己寫的**是否規範，別人可不可以看懂；2.別人寫的**，我能不能看懂。
1.對自己的**
回想起自己以前的**，真的不太「友好」，該有的縮排沒有，看上去就是「一坨...」。**風格規範應該做到：簡明，易讀，無二異性。首先說一下縮排問題，4個空格距離是最好的，所以我們可以在我們的程式設計工具（例如我用的eclipse）中設定一下tab鍵，固定為4個空格。其次要說的就是斷行與空白的{}行的問題，舉個例子，我在之前的程式設計中使用的風格是這樣的（程式設計軟體預設的，我也就適應了）：
if()；
if()
dosomething(}；
確實關係會清晰很多。還有一點令我印象頗深的就是對於變數的命名問題，我們不能為了簡便就隨意用形如a,b,c此類，而應該見名達意，既方便自己，也方便他人的閱讀。
2.對他人的**
平時我們可能也會經常需要閱讀他人的**，因為每個人的編寫習慣不同，我們需要盡量去適應，如若實在看不懂，應該尋找本人交流溝通。
快速閱讀《構建之法》 構建之法閱讀筆記01
自己從3月4日開始讀 構建之法 在粗讀一遍後，自己產生如下疑問 1.風格真的很重要嗎？總覺得清晰易讀即可 2.編寫軟體時，是程式簡潔高效但不易讀好？還是程式冗餘效率低下但是方便別人閱讀易維護好？3.使用者體驗主要體現在哪些方面？介面美觀，反映速度快，功能齊全足夠了嗎？4.本書只說了團隊模式，並未對如...
01《構建之法》閱讀筆記01
個人感受 我過去的做法 1 寫程式以實現功能為主要目的，所以有時候為了功能的保證，會不太注重演算法的使用。2 在團隊專案中，習慣了個人程式設計，和團隊成員溝通偏少。為什麼這樣不好 1 不注重演算法的使用，會無端的浪費空間和執行時間，使程式效率大大降低。2 團隊成員之間交流過少時，融合會經常出現問題，...
構建之法閱讀筆記01
從第一章概論中提到，軟體工程要創作足夠好的軟體。而有一些同學認為，所謂好軟體，就是沒有bug的軟體，所謂軟體工程，就是把軟體中的bug都消滅掉的過程，這確實抓住了軟體工程中的乙個要素，和軟體打交道的專業人士都知道軟體有bug，軟體團隊的很多人都整體和bug打交道，bug的多少可以直接衡量乙個軟體的開...