寫在最前
讀書筆記只是對於讀到的部分內容的想法看法寫下來，與全書內容不無關係也沒有全部的聯繫。想要知道全書在講些什麼，最好還是自己去翻閱原書。
關於想讀這本書
想讀這本書是因爲，自己屬於一衆普通程序員中的最普通的一員。人一普通，就只能是學習並遵循一些前人給予的好的建議，以此來規範自己的行爲。讀這本書希望先讓自己在拋開技術本身，對待一個技術類的工作的時候，有一套合格的工作素養。當然，這有一些捨本逐末。畢竟，技術到位了，很多職業素養就不是必須的。讀此書，也權當是培養職業化完成工作（不一定是技術工作）的意識與能力吧。
專業意味着擔責
犯錯無可避免
初看起來，專業和負責似乎是兩個不相干的詞，儘管都是正面的詞彙。可是，在bug總是在所難免，事故偶爾就會發生的程序與技術工作中，一個專業的工作人員（程序員）不是避免犯錯誤，而是能對事故負責。不少職業化“教材”向初入職場的人介紹的職場文化，永遠都是強調拒絕放錯誤。要知道，任何千辛萬苦建立的信任度，只要一次錯誤就會被毀滅。
而程序員寫出錯誤的代碼，或僅僅是不合規範的代碼都是常有的事，在大廠，提交的代碼鮮少是一次即過的，辛苦修改程度不亞於發表論文。即使在新廠小廠，看似不需要嚴格的代碼審查，後果是事故往往是線上生產事故。
所以負責是專業的表現之一。
不行損壞之事
雖然寫出有問題的代碼無法避免，但是在代碼做交付之前，應該保證這一段代碼是可以正常運行的，過得了測試的關的。不應該把沒有測試的代碼進行交付。大多數程序員都知道這個基本要求，但是一旦在頻繁的修改問題代碼或者解決事故的時候，容易因爲疲倦而懈怠。
這也是爲什麼要推行測試驅動開發。寫代碼之前先做好測試代碼的編寫，無論工程代碼進行什麼樣的修改，寫出的代碼都是可以經過代碼變異測試的。
只有當代碼過得了自己的關的時候，才進行交付。這是專業的表現，也是負責的工程師的表現。事實上，很多專業的工程師，代碼都是在交付的時候基本已經完成該有的業務邏輯的測試，幾乎不需要測試工程師再做一遍。否則很多初創公司在技術層面就已經失敗了。在業務邏輯之外，性能問題及代碼規範問題，隨着產品升級及技術升級，慢慢積累經驗，去避免錯誤。但無論如何，專業的程序員隨時都提醒自己不行損壞之事。
隨時給代碼做必要的修改
代碼重構是常發生的事情，不要等到發起重構項目的時候，再對代碼進行重構，更不要僅僅在每一次新增feature或者bug fix的時候順便做重構。這會使得重構只是爲了當前的問題，而忽略了設計本身的問題。
當然，有一種說法是，代碼只需要做當下的工作，不要爲未來做過多的設計。兩者似乎是矛盾的，權衡的方法沒有一套基本原則，只能是依靠工程師的工作經驗以及對業務的理解與業務未來規劃的瞭解。
無論如何，對於自己維護的項目，應該知道自己的代碼一定在編寫之初有哪些可能的缺陷或漏洞。儘管已經做出交付，仍然建議每一次都可以做一些必要的修改，不要懶惰擱置。相信每一次的修改對軟件本身、對自己技術水平，都是一種提高。