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

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

三十天鐵人賽的故事

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運用情境的說明,運用情境其實就是一個故事情境,下次輪到你來表達相關技術元素時,請記得你的對象是人,不是機器!

作者簡介


Advertisement

更多 iThome相關內容