《程式設計師修煉之道》讀後感

看到這個書名的時候，會不自覺的想起周星馳在《喜劇之王》中的經典橋段，手拿一本《演員的自我修養》激勵著很多懵懂青年。

就像這本書的自序所講的，這是一本包含有許多樸素的經驗，寫給注重實效的程式設計師的一本「演員的自我修養」。

剛剛步入程式設計隊伍的我，正需要這樣一本書給予我經驗，也因為是多年精心耕耘的結果，一時不能全盤收入囊中，只能讓思想先入為主，在開發中加以理解。

如何提問？

1：確切地知道你想要問什麼，並盡量明確具體；2：小心而得體地組織你的問題，記住你是在請求幫助；3：發郵件時請使用有意義的主題；4：坐回椅子上，耐心等候。

當你看到糟糕的設計、錯誤的決策和糟糕的**時，修正它們。在工作中，很容易對源源不斷的bug不耐煩，或許被自己說服僥倖繞過，以後就會有更多的直至難以修復。破窗戶講的故事是乙個小區的一扇窗戶沒有及時維修導致整個小區陷入被更多破壞的現實，人們再想起維修時，代價巨大，治安特別好的地區也對破窗嚴格治理。

讓學習成為習慣。程式語言、技術日新月異，小夥伴們都感受至深，幸運的是我們的知識獲得比任何行業都更加容易和方便，大量的社群，教程和熱心的作者。書中也給程式設計師提了幾點建議，每年學習一門新的語言，每個季度閱讀一本技術書籍等。

系統中的每一項知識都必須具有單

一、無歧義、權威的表示。其實我還是不太明白這句話，目前能做的，就是盡量不寫重複的**。

如果復用很容易，人們就會去復用。創造乙個支援復用的環境。將相同的功能抽離出來，可能會大量用到的方法使用靜態關鍵字。

曳光彈能通過試驗各種事物並檢查它們離目標有多遠讓你來追蹤目標。這應該是最近比較流行的敏捷開發了吧，快速迭代，在實踐中調整目標。

當圖形使用者介面無能為力時使用shell。自從用了ubuntu,我已經習慣了命令列操作，它能解放你的右手，這種感覺相當舒服，可以幫助我們自動完成一些工作。

bug是你的過錯還是別人的過錯，並不是真的很有關係——它仍然是你的問題，它仍然需要修正。勇於承認自己的過錯，這沒有什麼。

做一次深呼吸，思考什麼可能是bug的原因。記得剛入團隊時，我時常會對難以捉摸，尤其是不能復現的bug感到恐懼，但細細尋找，你還是能看到蛛絲馬跡。

使用合約建立文件，並檢驗**所做的事情正好是它宣告要做的。規定好我們要傳入的引數的型別，數量，將他們寫在注釋裡，並對不合約定的引數進行處理。

要配置，不要整合

要將應用的各種技術選擇實現為配置選項，而不是通過整合或工程方法實現。yii框架的元件便是這一思想的最佳實踐。

要根據模型和檢視設計你的應用，從而以低廉的**獲取靈活性。最近的nodejs好火，前後端分離是必然趨勢，純粹的模型測試起來也是非常方便。

無情的測試，不要讓你的使用者為你找bug

建立並維護專案中使用的專用術語和詞彙的單一資訊源。這一點深有感觸，為了方便，專案中通常會有一些簡稱，他對於業務人員是熟悉的，但程式設計人員卻不這麼想。

過去時代的手藝人為能在他們的作品上簽名而自豪。你也應該如此。坦白的說，簽名之後再看這段**會非常愉悅，有時還會陷入自我欣賞中，他其實還有乙個作用，我對**負責，我測試過並確保他的良好執行，也是一種自我監督吧。