最近看了《程序員的修煉之道-從小工到專家》，裏面講的是怎樣成爲一個注重實效的程序員。講的是程序員，但是其實中間的很多道理作爲一個職場人來說，都是適用的。因爲最近看得個人管理方面的書籍比較多，還是按照很多大師經常提到的道、術、器、用四個字來總結一下這本書，也是給自己的一個發展定位：我自己想要成爲一個怎樣的程序員。
道：一個注重實效程序員需要秉持的理念
書的第一章的名字叫注重實效的哲學。其實不像很多人想的那樣，程序員並不是一個冷冰冰的枯燥的集體。反而，程序員是更多善於思考的一個集體，不僅僅是對工作，對於人生、世界，程序員都有屬於自己的解釋。所以纔會有這麼多的程序員的紛爭，從大了講有自由與封建（開源/閉源）之爭；往具體處說，又有諸如UNIX哲學等哲學流派。但作爲一個注重實效的程序員，秉持的理念是怎樣的、他的人生觀應該是怎樣的？這本書的第一章給開了個頭。
注重實效的程序員在編程的時候，他們是完美主義和實用主義的結合者。他們對自己的代碼要求完美，對自己的錯誤負責，他們不能容忍破窗戶的存在，因爲它最終會導致一個失敗的項目。但同時，他們也知道在什麼時候止步，他們明白他們是在一個不完美的世界上開發代碼的，所以他們通常把質量作爲一種需求，而不是一個極大的簡單期望。
但是他們的世界是宏觀的，他們往往想要從更高的角度來思考問題。他們需要確認自己的每一步都是爲了自己的最終願景，每一行代碼都是爲了項目的完美實現。他們秉持着這樣的價值觀，不斷的判斷自己是否偏離了最終的方向。
另一方面，所有的高效的程序員都是進化論的支持者，所以他們十分注重自己的進化。他們往往會定期的投資自己，用知識不斷武裝自己，來適應不斷更新的環境。同時，他們不斷的同環境交流，很多時候是使用網絡或者書面的形式。同時，他們會讓自己的產品同樣是可進化的化，具有可撤銷性，來適應環境。
最終，是所有注重實效的程序員都堅持的一個原則：簡單原則。他們會盡一切可能避免重複，盡一切的可能進行正交的操作。
術：實現高效的流程方法
根據上面的原則，我們有通常的幾個規律來實現我們的項目。
當我們面對一個新的項目的時候，我們不應該過於詳細的進行每個模塊的設計，而是應該使用曳光彈，首先搭建起我們軟件框架。隨後，在我們缺的程序框架上進行完善。這樣能夠高效的優先確定我們的路徑。
隨後，當我們實現具體的功能的時候，我們可以使用原型，原型可以允許適當的忽略某些細節，來快速驗證我們的想法。
針對具體的問題，我們應該刨除編程語言的干擾，靠近問題領域編程，使用領域語言對問題進行有針對性的開發。
另外兩個適用的通用規律是估算和合約。我們應該使用合約對我們的項目需求和設計進行規範，我們應該使用估算對我們的項目建立模型，設定自己的計劃，隨後進行代碼迭代。
器：帶來效率提升的工具
從思想上提高了認識之後，我們可以從工具着手提高我們的效率。當然最先確定應該是我們的編輯器，一個高效的編輯器應該滿足下面的特點：
- 可配置
- 可擴展
- 可編程
使用適當的編輯器可以快速的幫助我們提高生產效率。此外我們應該使用適當的調試工具，及時的進行我們的測試和錯誤跟蹤。隨後我們應學會使用源碼控制工具，使用源碼控制工具不僅可以幫助撤銷錯誤的操作，還可以讓我們能夠快速的定位錯誤，自動化的進行測試。這是最重要的三個工具，另外一些可以提高我們工作效率的工具是：
- 純文本，它可以用來保存我們的配置、數據、歷史工作等，這是一種通用不過時的工具，可以協同我們的開發、測試，且不受特定語言和系統的影響。
- 命令行工具和腳本語言，有效的利用這兩者一方面可以讓我更加深入的使用計算機的很多功能，另一方面提供了我們自動化的方式來進行的我們的編碼、測試、乃至快捷地搭建我們的架構。同時可以幫助我們編寫自己的代碼生成器，避免我們進行重複的工作。
用：踐行高效的過程
1. 項目之前
在一個項目開始之前，我們需要的是深入挖掘需求，按照合約設計的方法，規範我們的項目。我們應該找到我們的設計的邊際，找到我們真正的約束。
2. 項目架構
對於軟件的架構，如上所說，應遵頊正交性的原則，這就要求我們將我們模塊之間的耦合降低至最低，有下面的方法幫助我們實現這個目的：
我們按照德墨忒耳法則來編寫代碼：
得墨忒耳定律－－對象 O 的 M 方法，可以訪問/調用如下的：
- 對象 O 本身
- M方法的傳入參數
- M方法中創建或實例化的任意對象
- 對象 O 直接的組件對象
- 在M範圍內，可被O訪問的全局變量
我們使用元程序的設計
使用我們上面提到的純文本工具，將我們的配置等抽離出來。將抽象放進代碼，將細節放進元數據。我們將時間解耦
將那些時間上不互相依賴的模塊解耦，提高併發性。使用合適的軟件架構，如：
使用 MVC 架構，將視圖和模型分開
使用 Blackboard 架構，協調工作流。
3. 項目編程
當我們編程的時候，應該首先保證程序的準確性，主要是兩個方面：
- 讓錯誤儘可能早的體現出來，而不是讓錯誤來破壞我們的代碼。
- 對於不可能發生的事情，應該使用斷言確保它不會發生。
另外，我們需要認清異常的意義：異常應該用於異常的問題，而不是那些我們自己需要前置判斷的問題。比如我們的資源使用，必須考慮到資源配平的問題。
其次，我們應在編程的過程中重視重構和測試的意義。