實現程式人心中的小說家

技術書籍作者Lynn Beighley在《Head First SQL》作者簡介，自稱為「困在技術撰稿人身體裏的小說家」，確實，許多時候撰寫技術書籍對我來說，就像是創造一篇故事，或許不少想撰寫技術書籍的程式人，心中都有這麼一個受困的小說家，等待實現與解放。

為技術元素及概念創造故事
雖不能說是全部，但許多優秀的技術書籍都有故事性，也許是藉由一個失敗的開發經驗、講述一個簡單的情境，或是展示一段醜陋的程式碼作為開始，再逐步揭示書中想要傳達的技術元素或概念，對於講述經驗或設計的技術書籍來說，更經常具備這樣的故事性。

O'Reilly書籍有個Head First系列，更全面採用故事性方式來銜接書中所有技術內容，使用大量圖片，如漫畫般展現問題需求與解決方案間的對話，讓讀者在故事引導下欲罷不能，從而快速且自然地吸收書中技術元素或概念。

每個技術元素及概念，背後本身就都有段故事，有時與其搬弄著抽象名詞或空泛描述，不如把它本身的故事陳述出來。如果本身故事太過複雜，就為它創造一個簡單的故事，這會使寫作技術書籍變得更有趣，也會使得陳述的元素或概念更為具體。

Martin Fowler在《重構：改善既有程式的設計》第一章第一句話，就以「我該怎麼開始介紹重構呢？」破題，因為每當有人講開始講述某東西的歷史、主要原理時，他的瞌睡蟲就會被誘發，所以他決定虛構一個簡單的影片出租店程式來作為起點。

當你決定寫書時，這表示書中打算說明的技術元素及概念，彼此有某種程度的關聯性，分辨出這些關聯性的順序並決定如何銜接，就造就了每本技術書籍的不同點；就像是小說中的故事元素，雖然都有主角、盟友、敵人、試煉等基本元素，如何串聯元素並發展情節，成就了小說的不同賣點。

有時，你不知道某個技術元素該怎麼開始說明，或者是覺得講述某個語法太過陳腔濫調時，試著想想它本身的故事，或者為它創造另一個故事，往往就能為你的技術書籍發展出不同的方向。

技術書籍的範疇管理
不少打算從事技術書籍寫作的人，也許是有感於過去被支離破碎資訊困擾所苦，也許是因為看到市面上爛書充斥之憤慨，或者是對自身專業知識豐富之自信，一開始會擁有雄心壯志，打算來個包山包海、鉅細靡遺的曠世之作，有時在寫作過程中，也會因為臨時的起意、旁人的建議等因素，對書籍本身加入越來越多的篇幅，然後，就像許多漫畫，在情節超展開之後，任何爛尾的結局都有可能發生。

Kent Beck在《Implementation Patterns》前言中談到：「和軟體開發一樣，範疇管理對於寫書同樣重要。」他緊接著，就告訴讀者「本書不是什麼」，確實地，決定書籍範疇時，決定「這本書不是什麼」比決定「這本書會是什麼」來得重要，這可以避免你在寫書的過程中，無節制地加入額外元素，也能幫助你明白地取捨讀者該是什麼樣的一群人。即使你是將技術筆記或部落格文章集結成書，決定「這本書不是什麼」，也可以讓你清楚地明瞭，哪些文章該放入書中，哪些只需要提供一個鏈結作為參考資料。書籍的範疇管理，後續牽涉到預計篇幅及投入時間，你可能會直接想到「我要寫多少頁」，以及「我要花多少時間寫」，不過，還得再想想「讀者要看多少頁」、「讀者要花多少時間讀」的問題，在範疇管理下預計篇幅及投入時間，要同時考量「作者」與「讀者」，就如同小說預計的讀者若沒有耐性，那麼鋪陳老半天還沒進入故事主軸，或者是看到老半天還沒有一個情節段落，他們看來必然索然無味，或者是注意力早已不集中。

類似地，如果預計的技術書籍讀者想在前百分之二十篇幅，就看到技術中常用的功能，那就不適合在開頭幾章就談盡技術理念與原理——無論你覺得那多麼重要。

當然，你還是得決定「這本書會是什麼」，這樣才能決定完成這本書的過程中，該有的里程碑（Milestone），具體來說就是書的篇章，各個篇章通常在書的主題之下平衡分配。如果某個篇章比例過重，也許在書名上就得作些調整。如果你無法決定篇章的比例，試著先開始撰寫第一章的內容，闡明這本書會是什麼。

在我的經驗中，第一章最難撰寫，有些人會建議整本書完成後再回頭來撰寫第一章，我不太建議這麼做，第一章的內容通常多少都宣告了這本書會是什麼，如果你難以下筆，通常就表示不夠清楚這本書會是什麼。

內容層次與編排
決定好篇章之後，接下來要開始實際編輯每章內容，在每章之下的各節層次安排，除了依內容長短與主題性關聯考量之外，還有一個額外考量點，你希望如何對讀者呈現書籍目錄？

好的小說，光看目錄就很吸引人，這對技術書籍也是一樣。在第一次翻閱書籍時，我個人的習慣是先看序或前言，接著瀏覽目錄，然後才是查看感興趣的內容，後續查閱書籍時，目錄當然也是很重要的依據，因而在編排各章時，這也就決定了你如何安排各節之間的內容。

多數書籍在目錄呈現時，至少會列出篇、章與節，因此篇、章與節的名稱意涵必須明確，且內容是重要的。有時，即使內容不長，但包括重要資訊，也可能獨立為一個節；有時，一個節下會有數個子主題，那就會獨立為數個小節。至於書的目錄是否列出至小節，就看這樣的資訊在目錄上是有意義或瑣碎而定了。

無論如何，不建議在小節之下再有更細的層次，像是4.1.2.3之類的，在目錄上呈現這部份就太瑣碎了，考慮將這類內容列點描述，如果像4.1.2.3這類層次出現太多次，或許暗示著4.1其實可以是一個章的內容，經驗中，若選書時在目錄看到太細的層次，那這本書通常會排除在我最後的書籍清單之外。

如同撰寫程式，現在鼓勵一個函式或方法不應過於冗長，以提高可讀性，編排書籍內容，也應注意每個段落不要過長，這跟最後書籍版面有些關係，通常建議每個段落佔三到五行，最好別超過十行。

每個段落間的空白，其實是一種視覺提示，道理與Bob大叔在《Clean Code》中〈Vertical Openness Between Concepts〉談到的類似：「提示空白行後方將接續著一個新而不同的概念」，實際上，《Clean Code》第五章有關〈Formatting〉的技巧，對撰寫技術書籍來說，有不少適用的概念。

即便是以大量文字為主體的小說，偶而也會加入一些插圖來引導或增加讀者對情節的融入，這點在技術書籍中也不例外，程式編寫為主的書中，除了運用程式範例來具體展示如何實作之外，也可適當使用圖片，而且在一群文字中出現圖片時，也提示著讀者這個圖片包括的概念是重要的，或者是冗長文字說明難以描述的概念。

別想取悅所有人
無論你想寫什麼主題，最重要的事情是記得，別想取悅所有人，就算是單純地寫小說，對情節有意見的讀者也是存在的，而技術書籍這塊，就如我先前專欄〈切入技術書籍的三個角度〉中談過的，在網路上進行搜尋，就可以找出許多技術書籍作者的抱怨文、碎碎唸或五四三。

我不確定程式人心中的小說家，是不是比真正的小說家脆弱，不過記得，寫出心中想呈現的故事才是最重要的，如此才能透過寫作找到自我。