用」僞代碼「裝飾你的程序

    記得在大學接觸的初級編程語言叢書都會推薦先用僞代碼來理清程序邏輯再用相應的語法和變量來實現程序。那時總認爲那是一種很低級的編程策略，耗費精力，浪費時間。因而在之後早期的程序生涯中，從未用過先寫僞代碼的形式寫過一次程序。

    但是去年的一次偶然機會，讓我完全改變對"僞代碼"的見解，那時在看一個同事寫一個web後臺的邏輯，我看見他首先在一個方法中用文字寫到step1：......step2:..... 若是......不然.......step3:.....（暫不實現的）TODO.....；在他寫這些文字描述時我就很清晰的明白了這個方法的做用，也理解了其中的邏輯，並且附加的，我給他提醒「你少考慮了一個錯誤處理"。我看着他寫代碼的方法，頓時有種發現新大陸的感受，對比本身之前寫代碼，老是在腦海裏構造一個個邏輯，而後就洋洋灑灑的寫開了，寫完後再經過閱讀代碼去檢查邏輯，要是時間間隔稍長，代碼量稍大，檢查自己就很耗費時間和精力，更別提從此讓別人去快速理解查看了，並且還經常有遺漏某個邏輯的狀況出現（俗話說得好：好記性不如爛筆頭。用在編程上一樣合適）。我想你如今明白我爲何要在」僞代碼「上加個引號了，你更能夠把他理解成爲一種代碼註釋（吐槽下：不少人會說良好的代碼是不須要註釋的，拜託說這句話前先問問本身，問問別人，有幾個那麼良好的人）。

    從此我寫程序就養成了這麼一個習慣， 對一個邏輯稍顯複雜的方法，總會先在腦海中構造其邏輯，而後一步步經過文字註釋的方式寫下來，而後檢查文字描述的邏輯，看有沒有遺漏的，不合理的地方，進行相應補全和調整，而後再開始寫代碼，等代碼寫完，註釋工做也完成了，對於從此代碼維護大有好處。並且在採用敏捷開發的團隊中，參與代碼評審的同事能夠從你顯著的邏輯意圖中就能夠斷定你的代碼是否合格。方便本身，方便他人，多好。

個人講解還過於簡單和隨意，建議閱讀 《代碼大全》第9章 僞代碼編程過程，會給你更好更專業的講解。