iThome 網站首載：實現程式人心中的小說家
技術書籍作者Lynn Beighley在《Head First SQL》作者簡介自稱為「困在技術撰稿人身體裏的小說家」，確實，許多時候撰寫技術書籍對我來說就像是創造一篇故事，或許不少想撰寫技術書籍的程式人，心中都有這麼一個受困的小說家等待實現與解放。
- 為技術元素及概念創造故事
雖不能說是全部，但許多優秀的技術書籍都有故事性，也許是藉由一個失敗的開發經驗、講述一個簡單的情境，或是展示一段醜陋的程式碼作為開始，再逐步揭示書中想要傳達的技術元素或概念，對於講述經驗或設計的技術書籍來說，更經常具備這樣的故事性。Oreilly書籍有個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〉的技巧，對撰寫技術書籍來說，有不少適用的概念。
即便是以大量文字為主體的小說，偶而也會加入一些插圖來引導或增加讀者對情節的融入，這點在技術書籍中也不例外，程式編寫為主的書中，除了運用程式範例來具體展示如何實作之外，也可適當使用圖片，而且在一群文字中出現圖片時，也提示著讀者這個圖片包括的概念是重要的，或者是冗長文字說明難以描述的概念。
- 別想取悅所有人
無論你想寫什麼主題，最重要的事情是記得，別想取悅所有人，就算是單純地寫小說，對情節有意見的讀者也是存在的，而技術書籍這塊，就如我先前專欄〈切入技術書籍的三個角度〉中談過的，在網路上進行搜尋，就可以找出許多技術書籍作者的抱怨文、碎碎唸或五四三，我不確定程式人心中的小說家是不是比真正的小說家脆弱，不過記得，寫出心中想呈現的故事才是最重要的，如此才能透過寫作找到自我，解放心中的小說家。