寫作

寫作是另一種開發

寫程式和寫文章，最後都在做同一件事：把一個模糊的念頭，變成別人可以操作的東西。差別只在編譯器換成了讀者的耐心。

很多人把寫作當成表達，把開發當成建造，於是覺得這是兩種才能。但真正做過兩邊的人會發現，卡住的地方一模一樣：不是不知道怎麼寫，而是不知道要寫給誰、要解決什麼、什麼時候該停。

先決定這東西給誰用

寫程式第一件事是問需求，寫文章也一樣。你要寫給誰看？他現在知道什麼、不知道什麼、為什麼要往下讀？這三個問題沒回答，句子再漂亮也是在自娛。

最常見的錯誤是「寫給自己看」卻以為在寫給別人。你腦中有一整套前因後果，所以省略了關鍵的一步，讀者就在那裡掉隊。程式也一樣：你以為顯而易見的初始化順序，對接手的人來說是黑箱。差別是程式會報錯，文章不會——讀者只會默默關掉頁面。

所以我現在動筆前，會先用一句話寫下「這篇要讓誰、在什麼情況下、多做對一件事」。如果這句話寫不出來，這篇就不該開始。

沒人會先寫一百行業務邏輯再想資料結構，但很多人會先寫三千字再想文章結構。結果就是每段都通順，整篇卻不知道在講什麼。

我的做法是先列小標題，只列動詞和名詞，不寫句子。這一步等於定義介面：每個小標題是一個函式，它要吃什麼、吐什麼，必須在寫正文前就清楚。列完之後我會做一次檢查——把小標題單獨唸一遍，如果邏輯接不起來，正文寫得再好也救不回來。

骨架還有一個作用：它讓你知道什麼該刪。沒有骨架時，每個句子都覺得重要；有了骨架，偏離主幹的段落會自己浮出來。

寫程式時，命名卡住通常代表你還沒想清楚這個東西到底是什麼。文章的小標題也是。如果你寫不出一個準確的標題，只寫得出「一些想法」「關於這件事」，那多半不是文筆問題，是理解還沒到位。

好名字有兩個標準：一是別人聽得懂，二是改不動。當你試著把「效能優化」改成更具體的說法，卻發現每個替代方案都不對，通常表示你其實不知道問題在哪。這時候該回去看資料，而不是繼續想形容詞。

初稿的功能是存在，不是好看。它的價值在於讓你看見自己真正想說什麼——通常跟你以為想說的不一樣。

所以第二遍一定是刪。刪掉「我認為」「某種程度上」「不得不說」這類填充；刪掉為了顯得周到而加的讓步；刪掉同一個意思的第二種說法。程式碼的行數不是生產力，文章的字數也不是。一篇能讓人記住一句話的短文，勝過一篇什麼都提到一點的長文。

刪的時候有一個判斷標準：拿掉這一段，讀者會不會少一個動作、少一個判斷？如果不會，那段就是裝飾。裝飾可以留，但要知道自己在留裝飾，而不是以為那是結構。

能刪到只剩骨頭還站得住，才知道原本那些肉是長在對的地方，還是只是為了看起來很豐滿。

我寫東西一定分版本。第一版只求把想法倒出來，不管順序；第二版調結構；第三版才修句子。這跟開發一樣：先讓它能跑，再讓它正確，最後才讓它漂亮。三個目標同時追，結果通常是三個都沒做到。

分版本還有一個好處：你不會因為改壞而失去原本的好句子。很多人不敢大改，是因為怕改不回原本那版。留下版本，刪除就變成一個可逆的動作，於是你敢下手。

程式碼裡最容易被低估的東西是說明文件。它服務的不是別人，是三個月後已經忘光脈絡的你。文章也一樣：你現在寫下的推理過程，是未來遇到同一個問題時唯一能回收的東西。

好的文件有三個特徵：說清楚為什麼這樣做、說清楚怎麼重現、說清楚什麼情況下不適用。缺了第三點，讀者就會把它當成萬用解，然後在失敗時怪文件。文章裡的絕對句也一樣，「永遠要」「絕對不要」寫起來很有力，但通常只是省略了前提。

有一種情況很常見：你覺得自己懂了，一寫就露出破綻。這不是表達能力差，是理解只到「能複述」的程度，還沒到「能推演」。寫作會逼你把每一步都攤開，於是那些靠感覺跳過去的環節，全部無所遁形。

所以我把寫作當成開發流程的一部分，而不是輸出的最後一站。一個功能想不清楚，先寫三百字說明它；一段程式設計不對，先寫下它的邊界條件。寫完還覺得順，通常就真的順了。

反過來說，寫得順不代表做得對，但寫不順幾乎一定代表還沒想清楚。這個訊號很便宜，值得多用。

最後回到那個比喻：寫程式是讓機器照你的意思做事，寫文章是讓人照你的意思思考。兩者都需要把複雜的東西拆到可以被執行的程度，都需要刪掉多餘的部分，都需要替接手的人留一條路。差別只在，程式錯了會當掉，文章錯了不會——它只會讓讀者安靜地離開，而你永遠不知道是哪一句話讓他走的。

這就是為什麼值得練。