iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 18
0

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

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

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

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

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

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

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

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

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


上一篇
為軟體訂定狀態階段
下一篇
減少漣漪
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言