想講的話自己的程式碼的可讀性隨著時間的過去會呈現什麼樣的關係
其實這關係可以用張圖來簡單的說明：
我自己的習慣是這樣的
- 先歸納整理一下這次要寫的程式要做的功能有哪些，接著開始大致區分規劃整個程式的大架構，這邊就包含幾點
- 初步規劃會用到的資料結構及相對應的 function
- 過程中大致上應該要區分成哪些 function，以及要如何串成完整的流程
- 在第一歩中因為我只會大致規劃，所以 function 內都是空的，接下來就是根據規劃好的內容開始去實做
- 測試與調整時間
第一步因為是架構的大規劃，所以其實我一般會附上還滿完整的註解去說明整個架構，包含會做哪些事、會需要哪些內容、會得出什麼樣的結果以及可能會修改到什麼東西。這時後的可讀性當然是最高的。
到了第二步開始真正動手填空時，可能還會多發現一些架構規劃時沒想到的小細節，所以會根據時做情況做細部調整，不過通常不影響整體架構，因此可讀性會略降，但也還好，因為整體上還是跟著當初規劃好的架構走。
到了第三步就是災難的開始 XD 因為這時後往往會冒出很多連架構規劃時都沒處理到的問題 (而且通常是一些源源不絕的特殊狀況)，當然在這種時後整個架構很容易被改得面目全非，甚至是為了那些特殊狀況要來個大翻修，如果又很不幸的因為時間壓力，這時後可能連註解都懶了 XD 當然可讀性也就... (默)
寫程式最怕的是特殊狀況，不過現實生活中沒有特殊狀況才奇怪 XD (我現在的這隻程式要處理的特殊狀況也是煩死人的一籮筐) 所以通常我設計架構時會習慣盡可能的保留彈性，只是事情往往可以比想像的還要糟，所以至今依舊沒有好辦法 XD
後記：身為 C++ 的重度使用者，非常佩服寫 C++ compiler 的那些人，有些特性光看就覺得複雜繁瑣，寫 compiler 的人心理的 OS 恐怕已經難以用髒話來表達了 XD
沒有留言:
張貼留言