今天想題目想了很久，終究是歷練少了點，有點油盡燈枯了。但還是靈機一動想了這樣的一個題目，這個題目不太好用千字篇幅去表達，不確定能否寫出個所以然，可能會有些抽象，總之盡力而為囉。

程式設計與軟體開發之所以有趣，有很大一部分在於解決問題的過程與成功所獲得的成就。各種解題方式都代表每一種思路，這些思路或是粗糙、或是精細、或是奇特、或是中規中矩。不管這些思路如何，在想出來時，都帶給我們很大的喜悅，我們也樂於和同好們分享。

但礙於許多現實因素，我們很難有太多時間與人面對面溝通，我們更多的時間是在面對螢幕、敲擊鍵盤，這些思路與我們的自豪沒什麼讓他人知道的機會，至少在透過面對這種方式很難。

我們更常使用的分享方式，其實就在我們的成果上。每行程式碼敘述、每個函式與方法、每套架構、每則版本控制的提交訊息、甚至每個我們需要命名的地方，這些都是我們用來表達思路的載體。如何留下思路，讓其他人看著程式碼或是版控紀錄就能聊解我們的意圖、我們的想法，這也是程式設計藝術的一個範疇。

為什麼圈內常戲稱，命名變數是程式設計師覺得寫程式最耗費時間或最難的地方，因為在命名變數就在在想要怎麼把自己的想法寄託在變數名稱上。若變數只是 a, b, c 的名稱，那我們的思路就如同被加密一般，旁人將難以理解。

每個版控訊息若只留下自己做了什麼，那也只是將變動的程式碼濃縮成一兩句話，至於我們當初是為了什麼而這麼做將無法被證實，後人也只能一個、個推測，卻無法得到肯定的答覆。唯有盡量留下當初的目的與為什麼這麼做的考量，思路才得以被留下來，我們在維護程式碼也才能暸解來龍去脈，而不只有單純的 Git Blame 與幹聲。

當我們絞盡腦汁的思考如何把程式碼寫得漂亮時，某種目的上也是留下思路。我們常思考著如何讓程式碼讀起來更好懂，當在這裡卡關時，不如先跳脫單純的程式碼風格以及規範，從留下思路的層面去想，或許就會變得簡單。

也因此，軟體開發就像是思路集合體，裡面記錄了來來去去許多工程師的想法。當我們在追蹤程式碼時，應該多想想當初編寫者在思考什麼，為什麼會這樣寫，去暸解他的目的、考量，再從程式碼去臨摹他當時的想法，這些思路才是該被我們挖掘的。語言特性和語法畢竟日新月異，現在記下再多規格都可能在不遠的未來被淘汰。唯有思路，是值得珍藏在腦海裡，且不斷被咀嚼與粹煉的。

在寫程式時，不妨多思考如何留下思路吧！與同好們共享知識、成就與喜悅。