程序員修煉之道（下）

Friday, March 30, 2018

15:17

就如同我在上篇讀書筆記中說的那樣，這本書中的一些方法和思想，需要我們在之後的編程學習過程中一點一點的參悟和領會。

曳光彈

比如說從我的第一次個人作業中，我對書中提到的曳光彈代碼就有了很深的感觸：根據書中給出的例子，我對“曳光彈”的理解是MVP，最小可用產品。甚至是比MVP更簡單，進一步最小化的，一段核心算法，一個可操作的簡單界面...等等。避免從復雜繁重的文檔和大而全的設計開始，直擊要害（或者說是你認為的“要害”），實現一個可供操作和評估的東西，觀察用戶的反應。一旦命中，再對其進行修繕和完備，反復在系統的各個部分實施這樣的動作，形成最終的產品。在這次第一次的個人作業代碼編寫中，有一個很重要的功能實現就是文件夾的遍歷，這是我所不熟悉的文件操作裏面的，但我可以應用曳光彈的這個想法，讓我的代碼在黑夜中發光！！

預備：我首先在網上查找相關系統函數的資料，然後寫了一段遞歸的代碼

開火：我將這段曳光彈代碼的輸出功能設定在簡單的輸出所有的文件名，然後用數據進行訓練

瞄準：根據這個簡單的輸入和輸出，我就可也直觀的看出代碼中間的核心邏輯部分是否存在問題根據問題指向就能輕松地對代碼進行修正。

這樣我就得到了一定沒有錯誤的一段文件遍歷的核心代碼，之後我再這個代碼的基礎上增加文件讀取等其他功能的時候就不會擔心文件遍歷這個核心邏輯的正確性。

同時就像書中所說，曳光彈代碼不是用過就扔掉的代碼，編寫它，是為了保留它。我同樣可以將這個沒有問題的簡單的讀取文件名稱的代碼保存起來，等到以後有用到文件遍歷的時候就在其基礎上進行開發。

代碼管理

在書中，作者在基本工具的建議中建議使用源碼管理工具。

在第一次的個人作業中，我使用了git作為我的源碼管理工具，在使用的過程中，發現了這樣做的好處。我可以大膽的修改我的代碼，而不用擔心我的代碼不能回到原來的版本。其次，我還能在branch中規範自己分支的主要目的，這樣可以明確目標。在git log中可以跟蹤自己的commit，跟蹤自己的開發進程，同時還可以通過github進行代碼同步和跨平臺開發。

調試

不要慌張。就像老師在課上提到的，真正有經驗的程序員會花上幾個小時的時間去修復一個bug而十分的平靜。

開始修復bug的最佳途徑就是再現bug

跟蹤，發現一個預料之外的壞變量時候，當你準備修復之前應該快速的看一下這個變量旁邊的幾個變量的值。

不要靠巧合編程

在書中，作者舉了一個例子，說明了很多時候，當我們測試時代碼沒有明顯的錯誤，但是之後出現bug很大的一個原因就是，我們根本不知道這段代碼為什麽可以工作

這裏和老師在課上提出的意見：不要復制和粘貼代碼，如果有需要，我們也應該一行一行的重新抄寫，同時，理解這段代碼的邏輯。

在這次的個人作業中，我就遇到了這個問題，在設計這個一個hash函數的代碼中，我為了可以是字符在表中可以盡可能的散開，我在網上找到了一段有名的hash代碼（針對於輸入字符串）。

然後稍微看了一下後直接替代了原來的hash函數，在小的數據集中沒有出現明顯的錯誤，於是我就覺得這段代碼沒有什麽問題，但是在應用到大的數據集的時候，就出現了大的沖突錯誤（我本來已經開了足夠的哈希表空間）但是還是放不下。一開始，我不能很快的發現問題所在，因為我以為這個hash函數是沒有問題的，在花費了大量的時間查找問題之後，才發想了這個問題出現在這個hash函數中，復制粘貼雖然節省了我幾分鐘的時間但是之後的debug卻花費了我數百倍的時間，所以我感觸極深。

不要猜想，要勇於嘗試

可以編寫，斷言來驗證我的猜想（斷言式編程）

結合我第一次代碼編寫的經歷，我在對string數據類型的還是操作時候不是很熟悉，不是很有底，在需要用的時候就會在shell裏面開一個小的程序來驗證我的想法，當然按照這本書的建議，我之後可能可以嘗試去使用assert斷言，

#include <assert.h>
void assert( int expression );

早測試，常測試，自動測試

不是很了解自動測試的概念，去網上查找了一下後，發現了幾款自動測試的工具，爭取下次用到個人作業或者結對作業中。

好記憶不如爛筆頭

要把英語（中文）當做一種編程語言

文檔分為外部文檔和內部文檔，內部文檔包括源碼註釋，設計和測試文檔，外部文檔包括用戶手冊，技術文檔等。

在這裏，作者推薦我們學習一下標記語言，可以提高效率。

所以找時間把markdown學一下。

《程序員修煉之道》讀書筆記（下）