從去年7月份開始陸續看了想SICP，CLRS,CSAPP和幾門相關的公開課以後（因為實力不足，這幾本書，幾門課都只是通讀了一遍），但看完以後寫代碼的心情就越來越逼迫。

於是買了鄒欣老師的《構建之法》和在udacity上選修了一門叫《programming language》的課（主要是用Python寫一個JavaScript和HTML的解析器）

現在《構建之法》看到第四章，心裏有一點小疑問，便記錄下來：
1：書中一直強調關於測試，命名，代碼規範，開發流程等相關東西。但我卻認為，如果一名程序員在構建過程中，最註重的不應該是程序設計和代碼抽象封裝之類的內容嗎。

我不是說代碼規範，測試，開發流程這些不重要。而是我買這本書本來是希望書裏面能告訴我一個真正的程序員中在實際開發中如何構建他的代碼。比如他要寫一個小遊戲（打磚塊），要他怎麽開始，怎麽寫擋板，寫子彈，寫磚塊。寫完這個遊戲以後，如果要開發另一個小遊戲，要怎麽把現有的代碼抽象，使得新遊戲可以使用打磚塊遊戲的代碼。在這個開發過程中，給我們普及一些比如命名，抽象封裝，debug等軟件工程的內容。所以我很懷疑，就是單純地列出這些標準。沒有相關練習和項目聯系的話成果會有多好。

但事實上，市面上也很少有書或公開課直接給我們如何從實際項目中演示關於如何測試，命名，（培訓班的不太算吧，看過一些培訓班的視頻都是所以材料都已經準備好了，包括遇到的bug也是準備好的）。SICP到有說，但是裏面說的內容和我們工作中的處理內容還是不太一樣的。所以說代碼風格各異也是有點原因的。

作為一名幹了一年的測試，總結一下開發在開發過程一些讓我很困惑的現象
1：對語言或開發的領域本身不夠了解。
2：開發過程代碼抽象封裝得不好，比如一個下載方法，他又在下載成功方法調用加載圖片的方法。
3：大家都看不懂對方的代碼和寫法。
4：沒有單元測試（沒錯，我司就沒有。。。）
5：一些邊界值，條件分支沒考慮全
6：不了解需求就開始做，或者說叫以為自己了解需求了。
7：懶，總想著這樣改方便一點，但是事實上改了這裏不行，又要改另外一個地方，最後忙了一天，最後還是用了我跟他說的方法。

到第四章為止有兩點我是很喜歡的：
1：是關於技能熟練度的，作為初始化個數組都要百度的我，看到這點更堅決了我接下來這段實際要多謝多讀的想法。
2：單元測試，作為一名測試，還不太會寫單元測試，真的罪過。。。。

讀《構建之法》