讀完《建構之法》之後最大感觸莫過于程式員修煉一節，程式員在自己的領域就像武俠小說裡面寫的一樣，每一個階段都有難過的坎，隻需要閉關冷靜修煉一下子就過去了，但自己感覺不對的時候，就倒過去看看自己在那一段修煉有誤，子曰：'學不可以已'的道理還是非常對的。資料結構和算法是比較重要的。大公司賣的是規範，小公司賣的産品，最小的公司賣的是服務。在大學裡比較的不是學習成績，而是個人的能力，雖然學習也是一種能力，但是其他能力不也得通過學習的來吧！通過大學裡上課的确學不到啥東西，但是有些東西你知道一點也不什麼都不知道強的多吧，是以我以前忽略學習是不對的。相對于讀本書我得到了另外的一些感觸：
一．背景差異
我是一個高職的學生，學習能力不怎麼強，對我來說很多程式可能就是封裝幾個寄存器操作函數，然後開始寫程式，寫到 哪兒算哪兒。軟體"腐爛"得很快，接手這種代碼的第一感覺就是必須重構了它。于是，吃了很多虧，才開始琢磨是否可以"複用"一些代碼，開始注意"功能"複 用，接着"架構"複用，"模型"複用。
這些意識上的轉變對于學生來說，需要很長的時間，而且他們的代碼量不夠，沒有吃過足夠的虧。但是，這不能成為不重視軟體思想的理由。任何涉及到軟體開發的崗位，都必須有軟體思想去指導實際工作。
二．"設計文檔沒可能寫得那麼細的"
這句話在很多小型的軟體公司中，經常能聽見。不少軟體項目負責人并不重視項目初始階段的軟體詳細設計文檔，隻是寫個大概，更像是為了證明自己是"正規 軍"，而走走過場。很多主導一款軟體開發項目的負責人，其本人并不是一個優秀的程式員，無法真正把需求轉換成相應的軟體模型，無法很好地進行抽 象。
在一個項目的開發過程中，需求分析，把需求抽象成相應的軟體模型，思考使用哪種設計模式，架構代碼如何擁抱變化。軟體工程師不能阻止需求的改變，隻能最大 限度地擁抱它。軟體應做到在隻修改配置檔案的基礎上自由地擴充和裁剪功能。這些是需要在團隊動手之前想好的，否則後期會很難受，尤其在項目進度壓力大的情 況下，一個需求的擴充可能就搞得整個團隊緊張兮兮。
三．在戰争中學習戰争
我最近在主導一個功率計的軟體開發，時間非常緊。有點像書中關于"團隊"模式中所提到的"主治醫師模式"，我通過與非軟體的同僚反複确認需求說明書中的條 款，避免因表述不清而出現歧義，并轉換成軟體設計文檔，文檔中包括對需求的解讀，如何用軟體抽象該需求，軟體模型是怎樣的，架構設計細節。最終，使用C語 言寫了個MVC模型（C語言也是面向對象的，好不好），采用"分而治之"的思路，并把繁瑣的邏輯拆分成獨立的"插件"，逐個擊破，通過配置檔案決定是否調 用某個"插件"的構造函數，實作"插件"的可插拔。
軟體工程中的團隊模式與足球中的戰術體系，在本質上是一樣的，誰動不動就強調他的個人能力，那麼他一定不懂得配合隊友，這是意識的問題。為了不斷提高自己 的水準，突破自身的瓶頸，我采用"做中學"的态度，結合《建構之法》中的原理，指導自己的開發工作，效率提升得很快。《建構之法》之于現在的我，就像《論 持久戰》之于抗戰初期的中共，具有絕對的指導意義。
與之同在的，我還在我做一個Web項目的時候寫的總結。