這本書翻譯過來的名字我總感覺怪怪的，英文原名是《The :From to 》,直譯過來應該是注重實效的程序員，這一點也一直貫徹著整本書，整本書主要就是為了回答這樣的問題，如何成為一個注重實效的程序員，如何成為一個注重實效的團隊？
這本書的適用范圍可以從初學者到有經驗的程序員再到項目經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年后說過，如果這本書是放在現在編寫，1999年的那些通用開發原則，在2009年同樣有效，假設我們今天才寫這本書，會與什么不同嗎？表面上可能會有些不同，我們可能會采用不同的編程語言和技術給出不同的案例，但這本書的本質不會變，因為軟件是人寫的，優秀的程序員都會采用務實和實踐的方法，知道的變化越多，掌握事物的基本原則就越重要。所以我也很有幸能通過這本書來糾正自己的一些不良習慣和掌握更好的方法，之后注意在工作的任何方面都需要注重一些基本的原則。看到自己犯過的錯誤，才讓人更相信這是一本經得起時間沉淀的好書。
個人而言，首先給我啟發的是通過溫水煮青蛙(昨天才在知乎上看到說溫水煮青蛙的時候青蛙也是會跳出去的，好想實驗一下啊！)的例子讓我們要持續不斷地觀察周圍發生的事情，而不僅僅是自己在做的事，尤其是項目的管理者必須要實時的掌控項目的方向，因為大多數項目失去控制都不是一下子就發生的，而是慢慢地，不可改變的完全失去控制的。可能是系統一個特性一個特性的偏離了規范程序員修煉之道 從小工到專家pdf，項目進度一點一點的拖延。這種情況下如果是作為個人還是管理者都不應該容忍規范的違背，每天、每周都需要審視自己，審視團隊，及時糾正問題，糾正團隊的方向。
貫徹全書的一個原則是DRY(Don‘t )原則，這也是每個優秀的開發人員必須要遵循的規范，編碼過程中任何地方都不要重復，因為重復暫時節省的時間將會給以后的維護使用帶來巨大的麻煩，如果發現代碼有重復或者違反正交性等原則的地方要立刻找機會重構。這樣才能夠擁有更快、更好、更強健、更優雅的代碼。
然后是關于文檔和測試，看過一個段子這樣說的，一個程序員最討厭的事情有兩件，一個是別人寫代碼不寫文檔，另一個是別人讓自己寫文檔。從這可以看出文檔和測試一直是程序員的最大的敵人之一，我個人在這方面習慣也不是很好，雖然會去寫文檔，但總是覺得編寫文檔和單元測試集成測試等會影響自己的產出，但在時間允許的情況下這才是對項目最大的負責，也希望每個團隊的管理員都能更有先見之明，不要太過于壓縮開發階段的時間，這樣才有助于編寫更好的文檔和單元測試，才會在后面的階段更省時省力。
耦合這個詞基本在我的職業生涯中每天都能聽到，一個好的程序一定是低耦合的，這本書提出了函數的德墨忒爾法則幫我們更好的界定耦合的邊界，怎樣編寫低耦合的代碼，更難能可貴的是這本書不僅僅描述了一般的代碼耦合，還花了很大筆墨解釋了時間耦合，很多時候一個業務的實現沒有必要一定是線性的，它可以是并行的，這在適用的情形下往往能在提高用戶體驗的同時還能降低系統的并發壓力。
另一個很重要的原則是不要隨意你不熟悉的框架和工具，現如今各種框架的功能越來越強，但與此同時各種底層的實現也隱藏的越來越深。如果使用了不熟悉的產品，卻不去理解它的底層實現，項目很可能是不受控制的，很多時候我們沒有能力去維護它，在碰到問題需要調試解決的時候會碰到很大的困難。
在工作中我們總會遇到難以解決的難題，本書給我們提供的一個思路是重要的不是你在盒子里思考，還是在盒子外面思考，而在于找到盒子-確定真正的約束，詳細一點的解釋就是面對棘手的問題時，列出所有在你面前的可能途徑，不要排除任何東西，不管它聽起來有多無用或愚蠢。然后逐一檢查每一項，并解釋為何不能采用某個特定的途徑。有時候你會發現，自己在處理的問題似乎比你以為的難得多，這種時候很可能你已經走錯了路，你需要回退一步，問問自己有沒有更容易的解決辦法。
最后一點是關于我們的傲慢與偏見，注重實效的程序員不會逃避責任。相反我們需要樂于接受挑戰，如果我們負責一段設計，或是一段代碼，我們都是在做引以為豪的工作。過去時代的手工藝人為在自己的作品上簽名而自豪程序員修煉之道 從小工到專家pdf，我們也應該如此，我們希望自己的名字能成為質量的保障，別人看見我們名字的時候就能知道它是可靠，用心編寫的，測試過的和有文檔的。
以上這些是我關于這本書的一些收獲的總結，只包括書中的內容的極少的一部分，更多的內容以及細節還是需要去書中尋找。這是我第一次讀這本書，但一定不會是最后一次，我相信今后的職業生涯里的很多問題一定都能在書里找到處理的方案以及參考的原則。