編程過程與思維狀態
編程是一個需要注意力高度集中的過程，不僅是編碼的過程，而且構建算法與數據結構的過程也必須如此。因爲整個過程可能有很多狀態，稍微不注意就會忽略或陷入混亂。人是高度進化的動物，能夠處理很多出乎意料之外的事情，但是計算機卻沒有辦法，如果出現之前未考慮的情況，計算機最可能的反應就是出錯與崩潰。
然而就算注意力完全集中，一個人大腦中的緩存也是有限的，不可能同時保持着那麼多狀態與變量的狀態，但人腦不會內存溢出，取而代之的是混亂。我們要清晰編程，而不要混亂編程。因此就必須應用從上至下，逐步求精的過程，先從問題的性質與規律入手，然後進行算法與數據結構的構想，等這一切都無懈可擊之後在開始寫代碼，編碼中寫好註釋，真正的編碼時間不應該超過整個過程的百分之三十。儘量在紙張上寫出相關的狀態與過程，以便於之後的參照。
進一步具體的說一下編程的過程：
1、問題探索過程，觀察思考問題的性質，找到問題及其對象中存在的規律，從而找到一種人能夠實現的有週期性的解法。
2、算法的求精與數據結構、模塊、接口的設計：將抽象性較高的週期性解法轉化爲計算機能夠執行的算法，將程序框架以及具體實現都設計好，最後的代碼就是這個過程結果的充實。
3、根據僞代碼編碼，在寫每個塊狀結構之前都必須註釋上這個塊狀結構的功能與實現。
4、debug與測試。
debug
debug是非常重要的，我總結的常用辦法有三個：
1、錯誤代碼段定位，縮小搜索範圍是節省時間的重要方法。
2、抓住一些關鍵的量（狀態指示量），將代碼的運行狀態顯示出來。不要讓代碼成爲脫繮的野馬，在寫代碼的時候，每一個結構塊之前都要註釋這一個結構塊的功能實現，在debug的時候，用運行狀態變量來保證代碼的運行情況在掌握之中。
3、利用大量的多種類型的可能輸入進行測試（對於初步運行正常的程序）
雖然debug技非常關鍵，但是一次性命中仍然是努力的目標，每次寫代碼都必須努力減少bug出現的機率，一個好的方法是分塊分段來寫程序，對塊段的測試bug的出現，也可以減少debug上的時間。
debugee1：當vertex[n]被聲明但n還沒定義的時候，DEV並不報錯，但運行的時候卻有時會出現詭異的錯誤，也就是vertex的地址發生改變，訪問vertex內的元素時出現崩潰。這個bug雖然是被編譯器放過而變得很隱蔽，但是仍然不應該困擾那麼長時間，因爲當系統中某一個環節問題的時候，你必須考慮它所有的元素是否都正常，如果能看到的元素是正常的，就必須考慮那些隱藏的元素。一個變量出現詭異的變化，不僅要看它被調用、修改的過程，也要注意到它的聲明與定義的過程。
debugee2：二維數組的傳遞需要列的信息，爲了克服這一問題，用一個指針數組來存儲這個各行的頭指針。
debugee3:算法與數碼實現的代溝，或者說是僞代碼與代碼之間的代溝，當你用抽象語言來期望完成某個功能的時候，用代碼寫出來卻會出現言不達意的錯誤。就像這裏，原來把if中語句放在for語句的中間期望完成同樣的功能，但實際上會出現bug。這類問題的解決方法在於編程過程的把握。
debugee4：debugee5：算法本身的漏洞，沒有把問題考慮周全，可能將同一個未訪問的頂點多次放入棧中。debugee5中指針指來指去比較複雜，容易出錯。這類問題的解決方法在於編程過程的把握。
debugee6：對於向量的應用不是很熟悉，對於迭代子也不瞭解，很多功能函數是基於向量迭代子的，所以，很多時候用迭代子比較好。但是如果直接用計數變量也可以，因爲可以用再一次計數方法來得到相應位置的迭代子。
debugee7：對於指針的new的理解模糊，實際情況是new一個空間，把給定的指針的值改爲new空間的首地址。因此，a=b，a=new int這樣的行爲會使a的值改變，但是不會使b的值改變，這是很明顯的。這是指針與普通變量的相似點。
附上代碼，代碼在DEV下編譯通過。（代碼有點亂，因爲同時用了鄰接表與鄰接矩陣兩種方式來鍛鍊下。）
