第六章：當你編碼時
不要靠巧合程式設計；不能存在僥倖心裡，靠巧合編碼，最後會發現**程式無法執行，或者錯誤連篇，修改的餘地都沒有，這樣最終受害的只能是自己。正如書中所講：要深思熟慮的去程式設計；總是意識到你在做什麼，我們寫**的時候要知道寫每一行的目的，用其來實現什麼樣的功能，有意識的去構思你的演算法，你的邏輯結構。不盲目程式設計，正如自己剛開始程式設計，拿到題目首先先把主函式名寫出來，定義變數等，邏輯結構、思緒等還沒理清就開始去著手敲寫**，這樣只會越寫越亂，最終無法實現功能。按照計畫行事、依靠可靠的事物、為你的假定設計文件都可以讓你深思熟慮的去程式設計。不要讓現成的函式方法來支配你將來要寫的**，要學會去改造，將現成的函式方法改造成你想要的方法，而不是方法支配著你去使用它。
重構：重構就是重新設計，重構可以實現函式方法的重新設計，但是其需要注意很多的事項。不要再重構的同時增加功能，這樣函式方法的原本質功能會得到改變，並且再重構之前要進行測試，確保你知道重構之後你的函式方法發生了哪些改變。
易於測試的**：單元測試；對功能模組進行功能測試，講乙個個通過單元測試成功的模組整合再一起便是乙個專案。但是再單元測試的時候也需要注意測試資料的科學性，全面性。針對合約進行測試，對合約中應該遵守的責任功能進行測試，看是是否實現了文件中承諾實現的功能。
第七章：在專案開始之前
需求之坑；不需要蒐集需求----挖掘他們，正像構建之法當中講到，當你蒐集使用者的需求時，有些功能使用者表達不清楚，或者有些功能使用者根本不說，這樣就導致我們蒐集的需求不夠全面，不能夠完全的滿足使用者的需求，這就需要我們去挖掘使用者的需求，站在使用者的角度去思考這款軟體或者**，能為使用者帶來 哪些方便。成為使用者，向使用者之所想，完全拋開開發者的角度來思考。與使用者一同工作，以像使用者一樣思考，建立需求文件。
傾聽反覆出現的疑惑----等你準備好在開始。傾聽反覆出現的疑惑並不是拖延，而是乙個良好的判斷，當年開始乙個新的專案前，你需要構建模型原型，並且對較難的知識點進行適當的儲備，如果你不知道這是拖延還是等待 一切就緒，也可以通過這種方法來檢驗。
《程式設計師修煉之道》閱讀筆記03
工具能夠放大你的才幹，你的工具越好，你越是能更好地掌握它們的用法，你的生產力越高，從一套基本的通用工具開始，隨著經驗的獲得，隨著你遇到一些特殊的需求，你將會在其中增添新的工具，尋找更好的解決方式。作為注重實效的程式設計師，我們的基本材料是知識，我們蒐集需求，將其變為知識，隨後又在我們的設計 實現 測...
程式設計師修煉之道閱讀筆記03
探索的態度對於程式設計師也是尤為重要的。筆者在開始寫 的時候總是以 解決問題就萬事大吉 的標準，遇到了可能的坑卻睜乙隻眼閉乙隻眼。但是每每這樣的時候，後來總是會出bug。其實這就是逃避，就是一種缺乏探索精神的表現。其實我把那些坑弄懂了也不需要多少時間嘛。弄懂了，以後再遇到就穩穩當當搞定了。沒弄懂，就...
程式設計師修煉之道 閱讀筆記03
由於本書的閱讀沒有先後之分，所以我跳過了幾章內容直接閱讀了第七章在專案開始之前和第八章注重實效的專案的內容，了解一些方法和理論。也得到了一些感悟。1 需求之坑 不為收集需求，挖掘它們。有一種能深入了解使用者需求，卻未得到足夠利用的技術 成為使用者。與使用者一同工作，以像使用者一樣思考。描述需求文件時...