為技術元素說故事

就工作內容而言，程式人應該是最常表達的人，只不過，溝通對象通常是死板的機器，表達的載具是程式語言，目的是令機器按照指示執行。

然而，面對活生生的人時，表達的載具是自然語言，技術元素的傳達目的，不在於執行，而在於令人心領神會，差別在於故事性，機器理解指令不需要故事，然而，人類需要故事來瞭解技術的概念。

三十天鐵人賽的故事

iThome鐵人賽是個非常有意義的活動，就我的角度來看，它完全強調出了傳達想法給機器與傳達想法給人的不同點，持續三十天寫程式給機器看很簡單，畢竟程式人幾乎整年都在做這件事了，持續發文也並不是這三十天的重點，真正困難之處在於，你得願意持續三十天地設身處地為其他程式人著想，盡力讓他們能理解這三十天內呈現的技術元素，你總是得問：「換做是我，會想看完這三十天的故事嗎？」

好的主題，當然是吸引讀者閱讀的開始，不過，好的主題並非憑空而生，你得瞭解故事中將出現哪些元素，就像處理排序問題一樣，你得安排這些元素登場的順序、場景甚至預想好最後導向的結局，然後才能決定出一個適當的主題。

在我寫作的經驗中，主題甚至經常隨著寫作過程不斷地調整，隨著內容的修飾，主題也會經過不斷地潤飾，這表示，若我想寫個三十天的故事，我會在六十天甚至更久之前，就試著寫出故事的大概，以便在開賽之前提交一個主題。

雖然鐵人賽是三十天連載，但是，不代表你當天才要來想當日的文章標題，如同真正的鐵人賽會有各個項目，得想好各個項目下如何調配體力，鐵人賽的三十天就是一個月，一個月有四個星期，也許可想想，各個星期的主軸是什麼。

舉語言為例，也許可切割為基礎語法、物件導向、標準程式庫、專案實戰為各星期主軸，然後在這主軸下調配七天的標題，記得為每個標題想個好名稱，如果你的主題是Java學習路，取名為Java學習路（1）、Java學習路（2）等絕對是很差的標題，一本書的目錄是這種流水號，你應該不會想看吧？！

要持續三十天，設身處地為其他程式人著想，絕對是難事。為了將想說明的技術元素做最好的呈現，能運用的絕對不只有文字，圖片、影片、程式碼等都會是可用來表達的方式。

單是文字，也有技巧可以運用。一篇文章拉得太長，讀者不會想看，因此BBS、即時通訊那種一句一換行的表達方式應當避免，不宜穿插過多表情符號，這會使得文字支離破碎。

單篇內容真的很多的話，應善用大標、標號等區隔每個概念的開始與結束；抓圖也不單只是抓圖，如果希望讀者看的動作，僅是在圖中的某個小區域，用個醒目提示框來加強它，會是個好方式。

三場研討會Keynote的故事

今年我有幸主講了Ruby Conference、Java Developer Day與Java Community Conference三場研討會的Keynote，這給了我不小挑戰，與分場議程最大不同的是，聽眾對於Keynote的主題無從選擇，只能選擇要聽或不聽，Keynote也往往肩負了炒熱研討會氣氛的責任，因此在主題選擇之前，得額外考慮為技術元素加上「原型」的概念。

此概念出自《作家之路：從英雄的旅程學習說一個好故事》，簡單來說，就是故事中人物的性格模式，像是門檻守衛、變形者、使者等，技術元素某些程度就如同故事中的人物，你可以賦予每個技術元素一個原型，這樣就能為技術元素來說故事。

在〈Understanding Typing. Understanding Ruby〉中，我特意選擇了一個具衝突性的標題，也就是使用動態定型的Ruby更要瞭解靜態定型，我在內容製造衝突，提出各種問題，像是：「動態定型一定得依賴單元測試？」、「Ruby無法宣告型態？」這就像是對英雄（Ruby）不斷提出考驗的「門檻守衛」，當英雄通過考驗，最後換來的獎賞，是對動態定型的Ruby更加能夠掌握。

在〈JDK8 Functional API〉中，從一開始我就避免談到Functional這個字詞，特意製造忽略的感覺，畢竟就熟悉物件導向的Java開發者而言，Functional本質飄忽不定、變化無常、難以掌握，如同《作家之路》書中「變形者」的角色，然而，從重構等實務角度來認識它的特色，對程式的可讀性與重用來說，都會有很大的助益。

在〈Java 8 Patterns〉中，模式代表英雄（舊版Java）過去已習慣的平凡世界，Java 8的Lambda等特性代表了「使者」的角色，提供了現況需要改變的動機，一開始的Decorator流暢化風格，只是個引子，最後導向了Monad、Functional Reactive Programming的可能性，這些可行模式的探討，代表著接下來在Java開發者世界可能面臨的重大變化。

九大演算法的故事

如果要你說明搜尋引擎索引、網頁排序、加密、壓縮等演算法，然而，對象是一群完全不懂程式的普羅大眾，有可能嗎？這需求並非憑空而來，有時面對不懂電腦的家人或朋友，是否曾希望他們多瞭解一些電腦技術，以免他們的電腦老是遇上一些奇怪的問題？John MacCormick在《改變世界的九大演算法》這本書中，就是這麼做的，雖是說明演算法，整本書中卻沒有任何一行程式碼。

單就標題而言，「改變世界」「九大演算法」無疑地會被我列入標題殺人法的分類之中，封面的簡介卻挽回了我的心意，其中列出了作者挑選這九大演算法的標準，前兩項是每天都會被一般使用者用到且解決現實具體問題的演算法，這就足夠吸引我了，而列出的九大演算法中，有些我也未曾涉獵，這些基本上艱深難懂的元素，如何能說得像是說故事一樣簡單？這些已引起了我的好奇！

用故事引導故事，讓讀者不知覺地進入主軸之中，是我見到的第一個技巧。在回顧了Google、Yahoo!與MSN三分搜尋引擎天下的時代後，作者進一步往前回顧至更早的搜尋引擎王者AltaVista，目的在導引出各搜尋引擎背後的基礎概念「索引」，為了避免讀者產生抗拒，作者先以巴比倫神廟中一片片楔形文字，表明了索引概念之古老，並以書籍最後的索引頁作為實例，讓讀者馬上印證了「這確實是我經常會使用到的概念」這樣的聲稱，然後在這樣的基礎上，一層一層地加上變化，說明了各種索引技法。

你可以把九大演算法這本書的演算法內容，當成你實際要瞭解的對象，然而，若你是個需要為技術元素說故事的人，無論你是要寫文、簡報或著書，分析作者如何說故事，也會是個豐富的收獲，主題、結構、內容、表達等各方面，都會是可以切入分析的角度。

程式人說故事的能力

在搜尋引擎鍵入「說故事的能力」，你會找到許多有關於說故事能力的重要性，然而，多半是在程式開發以外的領域，這或許與早期程式開發者多半特立獨行、離群索居有關，然而，現在的程式人已經不像《黑客列傳：電腦革命俠客誌》中描述的那樣了，在許多場合中，程式人也會需要說故事的能力，而不是單只是秀幾段程式碼、幾張架構圖，就冀望聽眾或讀者瞭解其中的奧妙。

還不能理解嗎？看看那些各大研討會的HashTag、HackPad等記錄，在談及一個場次的好壞時，應該能看到相關故事元素運用是否得當的討論，每個程式人也都有過死啃API文件的痛苦經驗，然而，即使是API文件也有寫得好與不好的，好的API文件，往往所多的就是那些API運用情境的說明，運用情境其實就是一個故事情境，下次輪到你來表達相關技術元素時，請記得你的對象是人，不是機器！