軟工讀書筆記 week2
阿新 • • 發佈：2018-03-21
邏輯 修改 ros 選擇 提醒 代碼 ont 語言 過去
2、純文本
純文本有很多好處，首先純文本格式不僅可以被機器理解，也是人可以理解的格式，這也就意味著它能夠保存更久。
其次，純文本格式具有簡單性，它也更易於測試。我們可以很輕松的增加、修改測試數據，也可以輕松地分析回歸測試輸出的結果，或使用一些腳本工具進行徹查。
3、源碼控制系統
我們應該總是使用源碼控制系統。因為我過去沒有進行過團隊編程項目，對一些源碼控制相關的工具也不是很了解。通過近期的認識，我愈發覺得源碼控制系統非常重要。它能幫助你對比不同版本直接的對比，幫助你返回之前的版本等。
團隊項目，不論大小，都應該使用源碼控制系統。雖然看起來有時候有些麻煩，但是養成習慣後對你整個項目都有非常大的幫助。
4、調試bug
我摘下了書中引用的這句話：
“看著你自己的煩憂，並且知道不是別人、而是你自己一人所致
——索福克勒斯：《埃阿斯》”
（1）接受事實
首先我們要接受這個事實。Bug已經出現了，你要做的失去解決它。而調試就是解決問題，我們要據此發起進攻。
（2）恰當的思維方式
其次，恰當的思維方式非常重要。不要恐慌，恐慌不能解決任何問題。更不要浪費時間在覺得那不可能上，因為事實就是，這個程序已經錯了。在學習C語言或者數據結構的時候，無論是平時上機實驗，還是大作業，總會有或多或少的bug。而每當遇到bug，總是調試不出來時，我確實非常容易陷入焦慮情緒。因為在我自己看來，程序完全沒問題啊。但是錯誤的運行結果又確確實實擺在眼前，只能硬調。
（3）小心近視
書中還提醒我們要“小心近視”。因為有時bug可能是在你以為的地方幾步遠的地方。而如果總是陷在一個點中，就會像我有時調試bug一樣，調試幾個小時，結果發現只是一個小小的變量打錯了。
（4）再現bug
要真正解決bug，我們要有能力將bug再現，也就是說我們要知道bug是怎麽出現的。只有知道它是怎麽出現的，我們才能學會避免它。
（5）橡皮鴨
這個概念，是我在數據結構課在大佬們的討論中第一次聽說的。調試bug一個很有效的辦法就是向別人解釋你的代碼，往往在你解釋的過程中，你就能發現bug所在。因為bug出現一定是和你的邏輯有關的。如果我們能夠從頭按正確的邏輯梳理一遍代碼，很大概率能發現代碼的漏洞。
（6）不要假定，要證明
不要輕易下結論“這不可能”，不要輕易放棄任何微不足道的地方。不要理所當然地去假定，而應該去證明它。
（7）讓下次修復更容易
修復完bug後，我們需要想想，我們可以做些什麽，讓下次修復更容易。比如書中提到的內建更好的測試掛鉤，或是編寫日誌文件分析器。
（8）早崩潰
讓程序崩潰是你的最佳選擇。這句話雖然單看有些怪，但就程序而言，一個死程序帶來的危害要遠遠小於一個有病患的程序。
《程序員修煉之道》這本書後面一部分則是更深入、更具體、更細致地就程序員應該註意的事項做一些討論，書中說的很多在過去的經歷中都有較深的體會，同時也給了我很多啟發。
以下是一些我感悟較深的點：
1、工匠與工具
工匠在使用工具的過程中，二者互相磨合，工具甚至變成了工匠雙手的延伸。這就好像我們學習與適應的過程。在學習初始階段，我們先精心挑選我們的工具。然後在使用這些工具時，不斷地熟悉，不斷地適應，工具成為你的大腦的一部分，它能放大你的才幹。
但是我們不能總局限於單一的工具，雖然有些工具看起來通用，但是當遇到一些特殊需求時，我們要像工匠學習，定期增加工具。就我自身而言，這方面我就做的不夠好。我個人就屬於習慣於一種後就不太願意更改的人。這一點不是很好，我們要樂於超越工具（如IDE）施加的各種性質。
2、純文本
純文本有很多好處，首先純文本格式不僅可以被機器理解，也是人可以理解的格式，這也就意味著它能夠保存更久。
其次，純文本格式具有簡單性，它也更易於測試。我們可以很輕松的增加、修改測試數據，也可以輕松地分析回歸測試輸出的結果，或使用一些腳本工具進行徹查。
3、源碼控制系統
我們應該總是使用源碼控制系統。因為我過去沒有進行過團隊編程項目，對一些源碼控制相關的工具也不是很了解。通過近期的認識，我愈發覺得源碼控制系統非常重要。它能幫助你對比不同版本直接的對比，幫助你返回之前的版本等。
團隊項目，不論大小，都應該使用源碼控制系統。雖然看起來有時候有些麻煩，但是養成習慣後對你整個項目都有非常大的幫助。
4、調試bug
我摘下了書中引用的這句話：
“看著你自己的煩憂，並且知道不是別人、而是你自己一人所致
——索福克勒斯：《埃阿斯》”
（1）接受事實
首先我們要接受這個事實。Bug已經出現了，你要做的失去解決它。而調試就是解決問題，我們要據此發起進攻。
（2）恰當的思維方式
其次，恰當的思維方式非常重要。不要恐慌，恐慌不能解決任何問題。更不要浪費時間在覺得那不可能上，因為事實就是，這個程序已經錯了。在學習C語言或者數據結構的時候，無論是平時上機實驗，還是大作業，總會有或多或少的bug。而每當遇到bug，總是調試不出來時，我確實非常容易陷入焦慮情緒。因為在我自己看來，程序完全沒問題啊。但是錯誤的運行結果又確確實實擺在眼前，只能硬調。
（3）小心近視
書中還提醒我們要“小心近視”。因為有時bug可能是在你以為的地方幾步遠的地方。而如果總是陷在一個點中，就會像我有時調試bug一樣，調試幾個小時，結果發現只是一個小小的變量打錯了。
（4）再現bug
要真正解決bug，我們要有能力將bug再現，也就是說我們要知道bug是怎麽出現的。只有知道它是怎麽出現的，我們才能學會避免它。
（5）橡皮鴨
這個概念，是我在數據結構課在大佬們的討論中第一次聽說的。調試bug一個很有效的辦法就是向別人解釋你的代碼，往往在你解釋的過程中，你就能發現bug所在。因為bug出現一定是和你的邏輯有關的。如果我們能夠從頭按正確的邏輯梳理一遍代碼，很大概率能發現代碼的漏洞。
（6）不要假定，要證明
不要輕易下結論“這不可能”，不要輕易放棄任何微不足道的地方。不要理所當然地去假定，而應該去證明它。
（7）讓下次修復更容易
修復完bug後，我們需要想想，我們可以做些什麽，讓下次修復更容易。比如書中提到的內建更好的測試掛鉤，或是編寫日誌文件分析器。
（8）早崩潰
讓程序崩潰是你的最佳選擇。這句話雖然單看有些怪，但就程序而言，一個死程序帶來的危害要遠遠小於一個有病患的程序。
軟工讀書筆記 week2