挑戰式的技術寫作

在現今遍地都是知識的世界中，就技術來說，官方網站普遍會提供文件或循序漸進的教材，技術社群中也會匯集各路人馬貢獻的資料，想從事某個技術主題的寫作之前，有時難免會想「有差我這一篇嗎？我為什麼要寫它？」

畢竟技術寫作就是技術與寫作，單純只是寫作，實在是虧大了，在技術寫作時設定挑戰目標，可讓寫作者在過程中獲得技術提升，看見不同的觀點，進一步讓文件更具獨創性。

挑戰有興趣但不熟悉的主題

大部份從事技術寫作的作者，可能是在某個技術主題中浸淫許久，累積夠多的知識、想法與經驗後，進一步想整理記錄，使之成為有脈絡條理的文件，我在先前專欄〈程式設計者的技術文筆與寫作〉中談的，大致就是這種寫作模式的意義與益處，這種寫作模式的目的在於疏理既有的知識、想法與經驗，本身也是種挑戰，在個人想法與經驗的支撐下，也會一定程度的獨創性。

挑戰有興趣但不熟悉的主題，又是什麼樣的模式？我會挑戰這個模式的起因是源於朋友的技術網站需要Java文件，初期修改了幾篇我自己網站上的文件並發表之後，覺得「這實在是太無聊了」，不過就是自己網站的文件改幾個字，然後在另一個網站張貼罷了，一點意思也沒有，還不如直接附上原文件鏈結就好，張貼幾乎雷同的重複資訊，充其量只是浪費時間，對我或文件本身都沒有任何貢獻。

為了讓寫作過程多點樂趣，我決定挑戰有興趣但不熟悉的主題，當然，不能有勇無謀，因而我挑選的主題還是與Java有關，因為從熟悉的生態圈出發，才能具備穩固的後援；而為了穩紮穩打，挑選的主題下具有概念分明獨立的子主題，這樣我才可以從容地思考個別子主題下的技術，如何使用？為何如此使用？以及進一步拆解為什麼可以如此使用？

攻破一個子主題之前，下個子主題仍是未知，是這種挑戰在過程中之所以有趣的地方，每攻破一個子主題都會有一種成就感，而這種成就感會自然溢於文件之中，當然，這樣的寫作模式下內容可能會不周全，雖然有缺點，但也是此模式下的另一樂趣。你會引來其他網友的挑戰，有錯誤的部份當然要修正，若只是觀點或論述重點不同，就別太擔心這種事，因為，天底下不存在完美的觀點與論述，其他網友的挑戰反而能讓你更確立，自身寫下的文件中是否表達出原本想呈現的觀點或論述重點。

挑戰從文件建立文件

在學習技術的同時，無論是官方或非官方，總是會有一些既有的文件，在閱讀的過程中隨時作些實驗、筆記、註解或心得，是常見的技術寫作方式，這大概是我經營自己網站時最常用的模式。

挑戰從文件建立文件，則是更進一步，要求自己針對官方或非官方發表的主題進行一次全新的寫作，如果已有英文文件發表過相同主題，在寫作過程中，時時慎防淪為翻譯；如果是中文文件，在寫作過程中慎防將既有文件換句話說，在別人發表過的主題下再度進行寫作，得更有更好的切入點、策略與方向。

挑戰從文件建立文件最好的切入點，就是自身感覺到官方文件不甚優良的時候。

舉例來說，托管在Google Code的guava-libraries，本身附帶的wiki文件無論是數量或範例，雖然還算豐富，然而，亦常見有開發者不甚明白運用程式庫的場合（Context）及運作原理，其中，大部份的疑惑是來自那些隱含著函數式風格的API，部份來自流暢Fluent API隱藏起來的實作細節，而這些是官方文件較少著墨之處，此時，可試著挑戰從這兩個角度來為guava-libraries這個主題撰寫文件，建立起對guava-libraries更深的認識。

挑戰從文件建立文件的另一切入點正好相反，困難度也較高，在官方文件或相關書籍文件寫得還滿完整的時候，可構思在這樣的情況下，再撰寫相同的主題，是否能有發揮的空間？

舉例而言，我的朋友qrtt1跟我談到，有些Gradle文件只是書上的東西再說一次而已，因為他自己看書也沒有很融入，因而想寫出那些，他覺得該有，而書上沒有放進去的主題，不是完整地介紹所有功能，而是介紹理解它的材料，與實際使用上比較需要知道的東西，qrtt1談到：「重複的工作，沒有太大貢獻，要找出新的產出形式，並且對整個知識的圈圈有新的貢獻」。

嗯？怎麼看起來，無論是文件好或不好，觀點都有點類似？其實重點在於，文件不可能滿足所有的人，從文件建立文件總會有挑戰的切入點，端看你在相同的主題下，將重心擺在哪個方向，當你有策略地朝著規畫的方向逐步挑戰成功，自然就會帶來成就感，連帶能滿足既有知識圈中的另一群人。

挑戰受制的條件

在寫作時設下限制條件，也是有趣的挑戰。

舉例而言，相對於我自己網站隨性的筆記，在撰寫iThome專欄時，我會有2600左右的字數限制，就這兩年的專欄寫作經驗發現，2600左右是個有趣的字數限制，這迫使我在實際撰寫文件前，就得預先構思文件中要有哪些綱要，每個綱要下得包括幾個概念用以形成段落，實際寫作時字數可能過多，那就得考慮將文件修枝剪葉，並抽取多餘論述中的相同概念，因而能更進一步探究主題下的本質，實際寫作時字數亦可能不足，這迫使我必須多做一些思考，因而發掘出更多寫作前沒有考慮到的觀點。

如果你對某個主題擁有寫出一整本書的熟悉度，技術寫作時可設下的限制條件，就是時間限制。

有時因為太熟悉了，要你在兩天、六小時甚至一小時內介紹該主題，反而是種挑戰，挑戰並非來自看完受限時數下的文件，就要能讓讀者飛天鑽地，而來自有限時間下，得呈現主題中最主軸、優良或精華的部份，並留下更多的參考文件或資源鏈結。有個網站〈Learn X in Y minutes〉就是這樣的概念，在幾分鐘之內讓你旋風式地概覽有興趣的語言。

設下更短時間限制的另一頭，就是設下更長的時間挑戰，就像〈iThome鐵人賽〉連續30天不中斷地發表文章，這代表你得事先規畫、構思30篇文章主題如何銜接，重點是你每完成一篇都得還有接續下去的動力，30篇算是滿多的篇幅，如果寫作的內容連自己都覺得無聊，或者純粹像在將書的重點謄到文章裏，就算你想事先寫好30篇，再逐日逐篇發表，十之八九也會無法堅持下去。

技術寫作時，亦可對主題設下環境限制，像是在完全不使用整合開發工具的情況下，逐步建立應用程式；在介紹Gradle的文件，乾脆就完全利用Gradle下載必要的程式庫、建立資料庫、啟動Web容器、自動化測試與部署等；或者在支援Groovy DSL的框架中，試著完全用Groovy DSL來完成組態設定，這些都是可挑戰的環境限制，完成挑戰後寫下的技術文件，也會是非常有獨創性的內容。

自身Level Up，就是文章的Contribution

Contribution這個英文詞，開發者應該相當熟悉，像是在GitHub上，開發者對特定專案的Contribution，可彰顯開發者在開發能力上的特質。類似地，想讓寫作文件時具有獨創性，也必須注重文件本身對該主題會有多少貢獻度。

近兩年我在寫作iThome專欄秉持的原則之一是：「如果寫完後，沒有任何Level Up的感覺，那就一點意義也沒有」，試著將這樣的概念放到其他的技術寫作中，就是挑戰式的寫作，挑戰意謂著有困難度，挑戰成功意謂著找到方案，在你感受到Level Up的同時，文件自然就會有貢獻度，也就是文件本身價值的所在。