又見對資料處理的苦笑

昨天在實驗室碰到 Hsu，他笑著向我吐苦水。

怎麼回事呢？原來，他幫項老師做計畫（寫程式），詩沛請他幫忙處理一些古籍 metadata 與文件之間的對應。然後... 他也碰上一大堆「不該有」的問題，隨便列舉幾個：

• 原先以為文件都是 Unicode Little Endian 編碼，處理後才發現有的文件依然是 Big5 編碼。


• Metadata 是用 Excel 編寫的。如果從外部呼叫 Excel 的Automation 元件，每個欄位的長度不能超過某個值_{（他有說一個數字，但我忘了是多少）}，但剪貼並不會有這樣的問題。於是，他只好先將 Excel 檔的內容匯出，然後再自己剖析 (parse) 輸出的文件。
  
  類似這樣的 Excel I/O 問題，屹靈_{（實驗室碩二的學弟）}和我都曾經碰到過。只是，解法雖類似（都先從 Excel 匯出檔案），但因為目的不盡相同、使用的程式語言也不太一樣，寫出來的程式（或格式轉換工具）彼此是不能互通的。（永倫也曾碰到反向的問題：產生一份 Excel 可讀的檔案。）


• 要寫剖析的程式，當然得先知道輸入字串的格式（或語法，syntax）。問題是，有些地方會出現莫名其妙的分斷字元或符號，而這些字元該如何被處理，往往需要重新檢視 Excel 檔的內容，然後以「經驗」再加上一些「Common Sense」來決定該怎麼做（直接捨棄這個字元、還是這個字元前後代表不同的欄位... 等等）。
  
  這表示，程式得因為這類「不在預期中的小問題」一改再改，程式碼最後可能會變得雜亂或醜陋，而增加日後維護的困難。

哇哈哈，你看，這些問題是不是在一年前我就曾碰到過、抱怨過？「垂直式的開發模式」就是會有這樣的困擾：每個人各自開發一個子系統，獨立解決自己看到的問題，然後... 類似（或甚至是相同）的問題反覆出現，每個人都得「重新發明輪子」來讓自己跑得輕便些。

厲害些的人，遇到這樣的問題，會知道如何去處理（但通常還是會抱怨、嘆氣、或苦笑一番）。實務經驗比較缺乏的學弟妹們，遇到這類「煩人的瑣事」，往往就會被卡住幾個星期、甚至數個月。

所以，會不會覺得很奇怪：處理 THDL 的資料，怎麼會遇到如許多的問題？

我認為，一個複雜系統之所以困難，有很大部分是來自於合作的挑戰，以及對「未來之不可預期與不確定性」的一致期許與規劃。這應該也是軟體工程所看見的問題與挑戰吧_{（當然，還有「降低成本」的挑戰。「工程」就是要在現實的環境下儘可能地滿足需求）}。