《程序員修煉之道：從小工到專家》閱讀筆記03

第六章 當你編碼時

靠巧合編程應該避免靠巧合編程，避免依靠運氣和偶然的成功。而要深思熟慮的編程。

怎樣深思熟慮的編程：1）總是意識到你在做什么2）不要盲目的編程3）按照計劃行事4）依靠可靠的事物5）為你的假定建立文檔6）不要只是測試你的代碼，還要測試你的假定7）為你的工作劃分優先級。把時間花在重要的方面。

重構：周遭所見，皆是變異與衰敗。代碼需要演化：他不是靜態的事物！不要對改動猶豫不決 代碼若具有如下特征，則應該考慮重構：1）重復2）非正交的設計3）過時的知識4）性能 就其核心而言，重構就是重新設計：怎樣進行利大于弊的重構：1）不要試圖在重構的同時增加功能2）在開始重構之前，確保你擁有良好的測試。 （盡可能經常運行這些測試，如果你的改動破壞了任何東西，你很快可以知道）

易于測試的代碼：單元測試< 測試你的軟件，否則你的用戶就得測試 >

第七章 在項目開始之前

需求只坑完美，不是在沒有什么需要增加，而是在沒有什么需要去掉時達到的。不要搜集需求而要挖掘他們！與用戶一同工作，以像用戶一樣思考！

解開不可能解開的謎題 解開謎題的關鍵：確定加給你各種約束，并確定你確實擁有自由度 < 不要在盒子外思考，要找到盒子 > 我們可以先確定最為嚴格的約束，然后再在其中考慮其余約束很多時候，對需求的重新詮釋能讓整個問題全部消失 ------ 就像戈爾迪斯結

等你準備好：有時猶豫的人會得以保全 < 傾聽反復出現的疑慮，等你準備好再開始 >

規范陷阱：編寫程序規范就是吧需求規約到程序員能夠接管的程度的過程 結構化程序設計 ------ 擁有長久的生命

第八章 注重實效的項目

注重實效的團隊：有了注重實效的開發者，讓他們工作在能夠發揮自身能力的環境中，他們很快就會發展并提煉他們自己的、有效的團隊動力機制

無處不在的自動化：軟件開發人員常常會使用最糟糕的工具來完成工作

無情的測試： < 早測試，常測試，自動測試 > < 要到通過全部測試，編碼才算完成 > < 通過”蓄意破壞“測試你的測試> < 測試狀態覆蓋，而不是代碼覆蓋 > < 一個 bug只抓一次 >

全部都是寫好記性不如爛筆頭：把英語當做又一種編程語言

個人感受：

靠巧合編程應該避免靠巧合編程，避免依靠運氣和偶然的成功。而要深思熟慮的編程。

看到這里，我不禁想問，套用模板的編程算是巧合編程嗎？答案是肯定的，因為沒有經過你自己的深思熟慮的編程都是巧合編程。就像老師說的那樣，總有一天你接到一個項目，你找不到對應的模板時，你該怎么辦？

代碼的重構：不要對改動猶豫不決，我自己本身就有這樣的問題，廢了九牛二虎之力碼出來一個程序，老師卻提出了新的要求，這時候我就開始猶豫了，怎么改動呢？從哪里開始改呢？

代碼若具有如下特征，則應該考慮重構：1）重復2）非正交的設計3）過時的知識4）性能 就其核心而言，重構就是重新設計：怎樣進行利大于弊的重構：1）不要試圖在重構的同時增加功能2）在開始重構之前，確保你擁有良好的測試。 （盡可能經常運行這些測試，如果你的改動破壞了任何東西，你很快可以知道）

轉載于:https://www.cnblogs.com/fuheishi/p/11061232.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的《程序员修炼之道：从小工到专家》阅读笔记03的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。