個人感受部分：
01.不注重重構**，軟體測試的時候總是避開bug走，不願意面對bug。
02.用更深的理解，變化的需求進行重新設計的軟體會更加優秀。在軟體通過所有可用的測試之前，你不能聲稱它可以使用。
03.學會重構自己的**，追求更好的體驗，認真的進行軟體測試，自助找出bug，以防後續出現問題。
讀後感：
關於重構，很多書都提到，我讀的前一本名著《夢斷**》也對重構這方面有著很詳細的講解。但是這本書的作者似乎有更深層的理解。隨著程式的演化，我們有必要重新思考早先的決策，並重寫部分**，這一過程非常自然，**需要演化，它不是靜態的事物。軟體與建築相比，軟體更像是園藝——它比混凝土更有機。你根據最初的計畫和各種條件在花園裡種植許多花木，你不短關注著花園的興旺，並按照需要作出調整。
重寫、重做和重新架構**合起來，稱為重構。那麼我們該在什麼時候進行重構呢？當你遇到絆腳石——**不再合適，你注意到有兩樣東西其實應該合併或是其他任何對你來說是「錯誤」的東西，那麼你不要對改動猶豫不決，應該現在就做。但往往現實世界特別複雜，當你去找你的老闆和客戶，對他們說：「這些**能工作，但我需要再用一周時間重構它」，你猜猜他們會怎麼回答？時間壓力常常被用作不進行重構的藉口，但是這個藉口並不成立：現在沒能進行重構，沿途修正問題將投入多得多的時間——那時將需要考慮更多的依賴關係。我們會有更多的時間可用嗎？
這學期大部分大作業都是團隊完成，不管是兩人合作還是三人四人小組，都可以叫做團隊。作者在最後一章，簡要的考查怎麼樣把各種注重實效的技術應用於作為整體團隊，這些說明只是乙個起點。質量是乙個團隊問題，如果團隊主動鼓勵開發者不要把時間花費在這樣的修正上，問題就會進一步惡化。顯然，團隊中的開發者必須相互交談。之前作者談過交流的問題，但是人們很容易忘記，團隊本身也存在於更大的組織中，團隊作為實體需要同外界明晰的交流。對外界而言，看上去沉悶寡言的專案團隊是最糟糕的團隊，他們舉行無章次的會議，在會上沒有人想說話，他們的文件混亂；沒有兩份文件有相同的外觀，每乙份都使用不同的術語。
確保一致和準確的一種很好的方式是使團隊所做的每件事情自動化，如果你編輯器能夠自動在你輸入時安排**的布局，為什麼要手工進行呢？如果夜間構建能夠自動執行各種測試，為什麼要手工完成測試表單呢？許多開發團隊用內部**來進行專案交流、我們認為這是乙個很好的想法，但我們不想花太多時間維護**，也不想讓它變得陳舊和過時。
軟體測試必不可少，但對於我或者大多數開發者來說，我們都討厭測試。大家往往溫和的測試，下意識的知道**會在那裡出問題，並且避開那些薄弱的地方。注重實效的程式設計師與此不同，我們收到驅迫，現在就要找到我們的bug，以免以後經受由別人找到我們bug所帶來的羞恥。一旦我們有了**，我們就想開始測試。許多團隊會為他們的專案精心制定測試計畫。有時他們甚至會使用這些計畫。但我們發現，使用自動測試的團隊成功的機會會大很多。你寫出了一段**，並不意味著你可以告訴你的老闆或者客戶，說它已經完成，不是這樣。首先，**從不會真正完成，更重要的是，在它通過所有可用的測試之前，你不能聲稱它可以使用。
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...