大部分從 Computer Science 領域剛跨進 Bioinformatics 的軟體工程師最不適應的就是有太多專有名詞了（跟當初剛加入趨勢科技有一樣的困擾），除了一堆又長又難念的拉丁字外，還有一堆撲朔迷離或說是曖昧不明的階層關係，永遠讓你搞不清楚。譬如說，在電腦網路通訊課程中一定會教到的 The 7-Layers of OSI model（圖一），從最㡳層的 Physical layer 到最上層的 Application layer 清清楚楚定義每一層的關係。
同樣的，生物資料是不是都如我們小時候學到的「界門綱目科屬種」這麼清楚的架構呢？之前試著要從 Genotype 串到 Phenotype 時就卡關了，原本以為不就 DNA=>RNA=>Protein=>Disease，但試著在放入 Transcript、Gene、Protein Domain、Protein-Protein Interaction、Pathway、Gene Ontology、OMIM、Cell Line、Organ、Epigenetics等元素進來時，誰要在誰的上面就有根據不同應用而產生各種派別，這可不是資訊人能想像的世界。
隨著生物技術的日新月異及支援相關各式各樣分析流程的需求大增，因而蘊育出生物資訊（Bioinformatics）專門學科來有系統地協助相關研究，這在台灣大約發生在 2003年左右開始蓬勃發展，之後有 system biology、computational biology等以系統化的計算能力解決生物問題；感覺很像 2013 年各行各業開始喊的「大數據(Big Data)」這個跨時代的科技演進，都是利用電腦計算能力來解決大量複雜資料的分析。我蠻喜歡圖二這個有趣的漫畫，雖然可能會得罪很多人。
也因為分析流程需要很多步驟及使用不同的分析工具，所以所謂的生物資訊學家(Bioinformatist)避免不了的一個重要工作就是：「串 Pipeline」。如同在 Hadoop Ecosystem 中一個專門在做流程控管的專案叫 oozie [1]，就是負責處理一連串有 dependent 的 Hadoop jobs，因為在分散式的環境中，如何確保每個步驟成功的執行及有正確的結果是個具挑戰的問題，如圖三所示，有些程式的輸入需要來自多個不同程式，他們就有執行先後的相關性。
同樣的，在生物資訊的領域中，要跑的工具是由各式各樣不同程式語言所撰寫的，如 Java、Scala、C++、Python、Perl，甚至有些是需要在 openMP、 MPI or Hadoop上。「如何有效地將這些工具串起來」是一門學問，但很多做 bioinformatics 研究的研究生們可能不以為然，他們會覺得他們研究需要提出的新方法才是最難的部分，相對於串 pipeline 只是一片小蛋糕 （a piece of cake），不就是寫寫 shell script就串起來了嗎？這個觀點我同意，因為我也經歷過相同的研究過程，程式怎麼改就是效率上還是輸別人、實驗的結果還是差別人一大截。但大家是否有過這樣的經驗：
在發表論文時，Reviewer 常常會要求與其它篇論文做比較，在有限回覆的時間壓力下，你要盡快看懂那篇論文及把相關實驗跑出來，但通常大部分的時間不是花在跑實驗，而是安裝那篇論文提供的程式。
不只程式跑不起來的問題，辛苦半天後終於跑起來了，但跑出來的結果與論文上寫的差異很大，到底是程式的問題還是自己沒裝好，該怎麼跑實驗呢？這時問天天不應、問地地不靈，問教授該怎麼辦，教授反問你想不想換題目多留幾年。
專業的程式開發，通常有 70% 左右的程式碼是與功能無關的，包括偵錯、容錯、跨平台支援、、、等。但大家能不能畢業只跟另外那 30 % 的程式碼有關，也就是只要做好那 30% 即可，另外這 70% 算是做功德，能做多少就做多少。所以才會導致 bioinformatics tools 在串 pipeline 時額外費工。
上個月曾和一位在 Stanford Medicine 工作的 Bioinformatist 聊到，他說他手上有上百個 Pipelines，每個 pipeline 只能在特定的運算環境中執行，有些是在他們的原本的 HPC 上跑，有些是在 DNAnexus 上跑，有些直接起 Google Cloud Platform 來跑。要把原本的 pipeline 移植到不同平台上跑是個大挑戰，因為很多 Pipeline 不是他寫的，是接之前研究人員留下的。這就如同你寫的程式只能在你的電腦跑，總是無法在別人的機器上跑一樣的問題。（這時專業的程式設計師就會回說： 「在我的電腦都可以跑呀！只能怪你跟這隻程式八字不合！」）
在 「The myths of bioinformatics software」[2] 第一條講得很傳神，每個 bioinformatist 都會認為我寫的 code 一定會有很多人用，但大部分情況都不是這樣子。主要是大部分開發者都不是專業的軟體工程師，寫的 code quality 太差導致，除了寫的程式沒有依照一般的 coding convention 外，很多 Error Handling 也都沒加，才會導致後續 Bioinformatist 使用這些工具時常常一個頭兩個大，兜出來的 Pipeline 總是會遇到一堆奇怪的問題。跑出怪怪的結果，回去查才發現在中間某個步驟時出錯了，但 Pipeline 還是一路繼續跑下去。
這篇文章先不討論如何讓你寫的程式變專業，因為專業的軟體工程師養成無法一蹴即成，但我們可以先來討論如何讓你兜出來的 Pipeline變得專業呢？只要做到兩件事，就可以讓你的研究心血不會因為以上的問題而無法跑：
- 可移植性 （Portability）
- 容錯力（Failover）
如何做到以上這兩個功能呢？其實不用自己處理這些問題，只要善用工具包裝即可。什麼工具可以同時幫我們解決 Portability 和 Failover 的問題呢？就是把你的 Pipeline 用「 Workflow Language」 來實現即可。那什麼是 Workflow Language 呢？簡單地說，就是另一種專門來串 Pipeline （也可以叫 Workflow）的 Language。「喔！天呀！又來一種新的程式語言嗎？」大部分的人第一次聽到 Workflow Language 的共同反應。之前，大家習慣用 Shell script 或 Script Language 直接來串 Pipeline，在移植到不同運算伺服器時，常常遇到不同 OS 版的函式庫版本不相容、Python 2 和 3 不相容、環境參數設定不同等問題而無法直接跑。目前枱面上有兩個主流的 Workflow Languages，一個叫 Common Workflow Language (CWL) [3]，另一個叫 Workflow Description Language (WDL) [4]。先為大家介紹 WDL，它是「由 Broad Institute [5] 所開發出來的」，結束。因為我也不熟，或者，應該說根本不想熟。
而 CWL 是由以下的單位所共同提出的，包括 Broad Institute：
大家對 Broad Institute 可能不熟，但做生物資訊的人應該都不陌生才是，因為他們提供了很多有用的工具 （e.g. Picard、GATK），套句某位台大教授說的：「這個邪惡組織，只要被他們做過的研究題目，大家都不用做了！」來恭維他們。可以看出他們加入 CWL 組織，但又自己推一套 WDL，這種背後應該有一些有趣的八卦可以去挖看看。網路上針對兩者的比較不多也不深入[5]，不過，找到一個有趣的比喻：
仔細比較一下 CWL 和 WDL 的 Spec.，會發現 WDL 比 CWL 來得像程式語言一點。 CWL 比較像 YAML 這樣層級的語法，而 WDL 可以有 function call 等 script language 的語法支援。眼見為憑，所以下面隨便截取一些程式片斷供大家參考參考（圖七和圖八）
舉 CWL 為例，呼叫 cwltool 就可以直接執行你的 CWL ，語法如下：
cwltool [tool-or-workflow-description] [input-job-settings]咦，不是只要準備自己的 CWL 就好了嗎？怎麼最後還有個 [input-job-settings] 需要準備呢？其實原因很簡單，這個 [input-job-settings] 是以 YAML 格式來表示 CWL 要跑的資料路徑或需要設定的參數的內容而己，也就是把 Arguments 寫到這個 YAML 中，這樣就不需每個 sample 都要寫一個相對應的 CWL。
大家可能還是會覺得 CWL 寫起來還是沒有我原本熟悉的 script language 來得直覺，CWL committee 也想縮短大家對 another programming language 的進入門檻，所以 SevenBridges 推出了 Radix Composer [7], 雖然目前還在 External Beta 階段，但提供 GUI 編輯介面（如圖九），使用者只要 Drag & Drop 即可產生 CWL了，也就是一開始建議大家善用工具就可輕鬆解決問題了。
看到這裡，心動不如馬上行動，一起加入我們「用對的工具提升自己 bioinformatics 的能力」吧！
[2] https://liorpachter.wordpress.com/2015/07/10/the-myths-of-bioinformatics-software/
[4] https://software.broadinstitute.org/wdl/
[5] https://en.wikipedia.org/wiki/Broad_Institute
[6] https://groups.google.com/forum/#!topic/common-workflow-language/xfNVJ5GvbH4
