The Builder's life #2: 撰寫程式、創作與火車月台

2018年夏季，為了養活自己並賺取未來讀台文所時的生活費，我投入了一間位於台中的傳產公司。

在傳統產業中撰寫銷售文案、企劃書等等的日常裡，因為一項緊急任務碰觸了 Python，並製作與腳踏車有關的簡易互動遊戲。名叫 Python 的奇特語言與過往書寫用的文字有著顯著的差異。緊密定義中蔓延出的確切意味、無法使用比喻這類模糊的形式、處處可見的等號、有著明顯範疇的邊界以及無法美化的錯誤訊息。在撰寫的過程中我以身體理解到，我用以寫作的語言與程式語言之間有著非常微妙的互動。原以為會感受到強烈衝突的我，驚訝地發現兩者交織成共生關係。

大學畢業後我即不再以稿紙創作，轉以敲打鍵盤為主。偶爾寫日記或是筆記時才會將那些字句寫在筆記本上。所謂書寫的手感轉移成手指在鍵盤上滑動的觸感，以及文句有著固定大小、固定行距，一定範圍還會縮排的視覺特點。由於共用載體，我可以滑順地在兩個編輯器裡切換，然而這並無法解釋中文與程式語言互相對話時的流動感，頂多只能以一般論解釋為什麼我可以完成這類任務而已。以結果論而言，程式本身以我無法掌握的範疇影響了我書寫的方式，而我書寫的方式也影響了我撰寫程式時的堅持。

我認為其中具有兩個原因：寫作與撰寫程式皆是可以讓我產生滿足感的行動、程式要求的嚴謹性與我書寫的方式相近。

創作

創作之於我的重要性在於它丈量了我一日的收穫，對於這件事，這個世界提供許許多多方法，有些人是金錢衡量、有些人以對話的質量，有些人依憑感受性的事實等等。而我則是藉由重新審閱，今日是否寫出了值得留存的段落來判斷。在這無中生有的歷程裡，我感受到了任何行為都無法提供的滿足感，與其說我是疲憊入睡的，還不如說我是以這種滿足感為食糧才得以安穩入睡。撰寫程式也提供了相近的感受，更有甚者，它提供了具體且可以用數字衡量的基準。

程式在每個階段的完成都會給你非常清楚的指標，unitest 過了，環境順了，與其他服務對接了。與撰寫長篇小說那被延後的獎勵不同，撰寫程式時系統會讓你知道你獲得了幾個小勾勾。這些立即的獎勵推動著我從蹣跚的初學者，一步一步走進這話語繁雜、喧嘩的世界。

程式與創作共同的方法論

程式要求的是嚴謹定義，準確除錯，由上而下編列的邏輯。以糖霜形式存在的還有重寫的價值，細小模組的規劃、說明性的文字等等。這些性質與我在創作上的方法論相近。其中我想明確指出的有實驗性的模組以及所謂火車月台這件事。

每一日的寫作之中，我並不是把所有東西倒進鍋裡，隨意攪一攪，期待裡面神奇地冒出讓人讚嘆的事物。而是非常科學化地去嘗試各種不同的組合，並且理解每種組合呈現出來的結果後，再嵌入原有的脈絡。這個過程在寫作中是以草稿後的重新書寫完成。在重寫的過程中我會把多餘的段落切分出去，或重新分配給另外一篇文章，端看兩者會有什麼化學變化。像是把馬鈴薯的塊莖切下來一塊緩緩發芽似的。

而在寫程式時，由於時常會寫到有相同結構的組件，每段時期，甚至只間隔半天到一天的時間，你所獲得的嶄新資訊就可以讓你寫出與過往截然不同的程式。一但習慣這樣的演進結構，就可以擺脫想要讓第一版就完美的陷阱，同時讓整體流程更加流暢且簡潔，創作時不會忽然滑上去兩個小時前寫的段落，接下來一兩個小時都陷入某個當時就已懷疑已久的句子，且這些過往書寫過的初稿都可以作為未來進步的養分。

於是寫作與撰寫程式的方法論，不斷強化彼此的規則，我感受的一部分的流動感即來自於此。

火車月台

另外一個特質是所謂「火車月台」這件事。這不是我提出的比喻，而是內田樹在評論村上春樹的論著《小心村上春樹》中提出的觀點。他認為村上春樹作為一個作家高明之處在於「巧妙地建設火車月台」這件事。月台存在的目的在於讓乘客有一處可以踏上的土地，如果沒有火車月台的話火車是不會也不能停靠的。如果一篇故事從最一開始就沒有火車月台，或是沒有與火車軌道好好對接的話，沒有讀者可以找到下車之處，他們無法藉由閱讀的行為獲悉作者的意念。

有些作品的火車月台反而是評論者建造出來的，而有些評論者蓋出的火車月台還比作者完善。

我認為寫程式也有建設「火車月台」的問題。且這個問題以更迫切，更至關重要的角色冒了出來。創作時建造火車月台的急迫意味可以等到第二次重寫，甚至等到親近的人查閱之後再來處理，更有甚者，從一開始就果斷地不建設火車月台。然而撰寫程式不能這樣，程式不是拿來讀，而是拿來用的，拿來用的事物與創作故事有著本質上的差別。被使用的物品有著解釋自身用途的責任。除了使用外還有維護上的問題，所以火車月台如果從最一開始就蓋歪的話，不僅造成維護上失誤的風險，更會導致他人的負擔。

火車月台的比喻在程式中轉以非常務實的方法論存在，例如程式架構的解析、利用 unitest 來讓人明白資訊流動的方式、範例程式講解如何使用等等，都是火車月台的體現。

我在撰寫程式時習慣將變數的意義劃分清楚，動作的話需要用一般句主詞、動詞、受詞的方式來建立，例如更改隱密條件的視窗就會被我命名為 changeAccessPolicyModal，單純表達狀態的則以形容詞和名詞堆疊，例如說當前節點的數量則這樣寫 current_hologram_nodes_amount，至於是 Camel、Pascal 還是 Underscore 則端看該環境的慣例是什麼。（我比較喜歡 Underscore）之所以要如此麻煩的原因就是在處理「火車月台」的問題。

火車月台與創作的節奏感

清晰地在程式的場域建設過火車月台，回到創作的場域裡後，覺察的能力增強了。哪裏要把火車月台的門打開，哪裏需要架設新的月台，以及什麼時候要適當地把月台拆掉，種種意念在腦海裡以更清楚的形狀呈現了出來。這裡有趣的事實是，寫作時常在講的「節奏感」可以以火車月台適當地具現化。所謂的節奏感可以指稱許多範疇，例如書寫的文句長短，文字的音律性。但在這裡我想要指稱的是：資訊量的閥門。撰寫小說很重要的技藝是知道什麼時候要解釋，什麼時候要闔上嘴巴。謹慎地提供資訊這件事至關重要。

例如當講述一場戰爭時，甲方輸的原因可能有三個。該如何在描述戰場時序時有意識地安排並揭露這三個原因，是要在最後才由勝利的那方講述，還是在最初就埋下因子，並為了營造神秘感而藉由一個老人之口說出預言那般的事物。又或者在戰爭的途中不斷插入記憶的片斷。這些都是與火車月台相關的問題。

把火車月台這種比喻作為一種可以實際操作的行為具象化之後，節奏感這件事也變得清晰起來。作為一個作者只要知道在什麼時候應該要打開月台，什麼時候應該拆掉就可以先天地掌握節奏感的命題了。

我所感受到的是

在創作之中，我感受的非一般性事實是，這是我的滿足感、成就感的來源，不是量化的結果，而是質化上非常任性且獨斷的感受。我喜愛創作，而從這個火車月台延伸出去的是，撰寫程式於許多地方和寫作有著許多相近之處，在這兩個任務交替的過程中，兩者不是對立的狀態，反而是藉由彼此的特性進而深化，成長了。

致謝

謝謝晏如、示家、子宇、柏鈞、敬智閱讀這篇文章的草稿。