注重實效的程式設計師的特徵:
care about your craft 關心你的技藝
think about your work 思考你的工作
1．注重實效的哲學
我的**被貓吃了。
--負責
破窗理論。
--軟體的熵
定期為你的知識資產投資
2．注重實效的途徑
dry--don't repeat yourself原則。
注意:**與文件的關係。我們可以在**的單元頭寫清楚模組的設計和使用方式,而不是外部的文件。文件和**是知識的不同表現形式，所以要搞清楚什麼東西應該寫文件，什麼應該直接寫在**檔案中。
正交性--***的各個控制器斷然不是正交的。
正交性和dry在某些情況下會存在表面上的衝突。
可撤銷性--擁抱變化(系統的靈活性)
注意:靈活不等於複雜
曳光彈--原型與曳光彈的區別:原型是用過就扔的**,而曳光彈構成了最終系統的骨架的一部分。原型製作是第一發曳光彈發射前的偵察。
領域語言--考慮為問題領域構造乙個小型語言然後自動生成相應的**或者元資料。
平台是領域語言嗎？可以嘗試給gbq構造乙個領域語言。
3．工具
純文字的威力;
報表改造後，可以使用簡單文字作為配置，便於svn比較，便於以後的自動化（比如自動化的公升級），便於閱讀。
大量使用shell;
精通一種編輯器;
學習一種指令碼語言;
下一步需要學習一下python，也許可以通過指令碼語言替換掉我們日益增加的工具。shell結合指令碼應該可以做很多事情。
製作**生成器;
在報表改造中，我使用delphi提供的opentools實現了部分**的自動生成，發現**生成器還是很爽的。以前我們的思路是通過配置減少一些簡單重複的**，導致配置特別多，而且邏輯分散在**與配置中。但是如果我們考慮自動生成一部分**的思路，既可以減少初期編碼工作，而且程式的邏輯可以集中在**中，便於以後的維護。
4．注重實效的偏執
按合約設計,早崩潰,斷言程式設計
5．彎曲,或折斷
元程式設計:把抽象放進**,細節放進元資料;用接近領域語言的方式表示元資料;
有點類似我們現在的配置方式（配置應該可以算元資料）。只是我們的元資料非常接近程式設計師，而不是領域語言，或者說我們還沒有乙個成熟的領域語言。
時間耦合:
檢視:mvc原則
黑板:降低耦合性
6．當你編碼時
靠巧合程式設計:一開始就不知道它為什麼能工作
以前經常靠巧合改bug。以後一定要搞清楚原因才能fixbug。
怎樣深思熟慮地程式設計:
（1）總是意識到你在做什麼
（2）不要盲目程式設計:試圖構建你不完全理解地應用,使用不熟悉地技術。
（3）按照計畫行事。
（4）依靠可靠地事物。
（5）為你的假定建立文件。
（6）不要只是測試你的**,還要測試你的假定。
重構:早重構,常重構
（1）不要在重構地同時新增功能
（2）重構之前,首先確保良好地測試。
（3）使用短小地,深思熟慮地步驟。
易於測試地**:
為測試設計;
構建測試視窗;
總結:一切都是自動化;
要把人類從簡單重複的勞動中解放出來，然後把cpu累死。可以嘗試一下文字結合指令碼的威力。
早測試,常測試,自動化測試;
在報表改造中加入了自動化測試，做的時候就比較有底。
把文件建在裡面,把文件寫在**裡(自動通過原始碼產生文件);
準備在改造完的報表模組中嘗試一下自動通過原始碼產生文件。這樣應該就可以解決改了**還要同步文件的問題了。
《程式設計師修煉之道》讀書筆記
第1章 你的知識資產 隨著你的知識的價值降低，對你的公司或客戶來說，你的價值也在降低。管理知識資產與管理金融資產非常相似，管理金融資產基本遵循 1.嚴肅的投資者定期投資 作為習慣 2.多元化是長期成功的關鍵 3.聰明的投資者在保守的投資和高風險 高回報的投資之間平衡他們的資產 4.投資者設法低買高賣...
《程式設計師修煉之道》讀書筆記
出了問題後，要提出各種解決方案的選擇，而不是找藉口 不要說事情做不到，要說明接下來做什麼來挽回局面 我們看到過整潔 執行良好的系統，一旦窗戶開始破裂，就相當迅速的惡化 不要留著破窗戶不修 發現乙個bug就修復乙個，如果沒有足夠的時間進行恰當的修理，就用木板先訂起來 或許你可以先把 注釋起來，或是顯示...
程式設計師修煉之道讀書筆記
1.無處不在的自動化.q 你目前是否在gui中用手工做一些事情？你是否曾將一些說明發給同事，其中涉及許多 點這個按鈕 選哪一項 之類的步驟？它們能自動化嗎？a 其實有很多自動化工具可以進行錄製動作，是否可以通過錄製過程，自動生成這種文件。2.強大的編輯器，這方面我比較很弱，需要改進 3.原始碼控制，...