過了需求訪談後，在設計和開發階段也有要注意的事項。

第一坑 資料不熟悉

當組織規模一大，設計資料產品的人可能需要從其他人的手伸認識資料，這種時候就會發生很多誤解或溝通障礙。
以一間上市公司來說，資料倉儲的表至少也有將近千個，光是要弄懂現有資料的特性就要花上許多時間，如果不同的資料有各自的所有者，就還要需要跟不同人去了解細節。

可能有人說有文件可以看啊，但就像前面說過，資料產品是「活」的，即便資料格式沒有改變，但統計數值或概念還是會隨著時間改變，這些改變也不會記錄在文件中。

第二坑 孤獨且漫長的探索過程

第二個坑也是滿深的體會，過去待過的公司有大有小，資料團隊少則三人、多到數十人都有。但不論團隊人數多寡，資料分析師/科學家在產品開發的過程中，很難跟其他人協作。如果是一個比較長時間的調查資料（例如零售業調查），還會有些在這個產業資深的同事，可以指出資料中可能的問題或是提點分析的方向；但如果是比較新的資料應用，在探索資料的過程是有點難跟其他人分享，沒有真正碰過資料的人很難知道資料的特色，只能根據分析師的結果進行討論，中間處理資料的細節假設有問題也很難被發現。

第三坑 不良的開發習慣

很多製作資料產品的人，往往沒有很豐富的軟體開發經驗，這些不良習慣可能會埋下往後在部署或是維運上的隱憂。這些習慣包括：

• 開發環境管理
  例如在自己電腦上裝了 N 種 Python 版本、不確定哪個套件裝了哪個版本、明明已經裝了但是 import 找不到、不知道自己寫的這支程式有用到哪些套件等。

• 不當的 Method
  很多資料分析師/科學家會使用 Ipython Notebook 之類的工具開發。這類工具能夠及時提供程式執行的結果，也能在界面上畫圖呈現的確非常方便。但由於這類工具是以 Cell 為執行單位，所以不太需要寫出很精簡的 Medthod 也能執行程式。這樣會造成程式沒有明顯的結構以及看不出方法之間的呼叫關係。

• 紊亂的程式結構
  呈上，這類的工具是以 Cell 為單位來隨選執行，有些開發會使用「自己的邏輯」來執行這些 Cell（可能先執行第一個、第三個、第五個、再跳回第二個），沒辦法很有條理的控制這些 Cell 的執行順序。這樣子除了後續難以管理外，也會造成程式複用上的困難。

• 隱藏的效能問題
  呈上，Python 在分析上是方便，但在效能上有滿多問題。大家熟悉的 Pandas 或一些視覺化套件都沒辦法做到分散處理。小規模的實驗沒有問題，但是一但處理大流量的真實資料就會不堪使用。

第四坑 測試難，難如登天

做為要上線的軟體，測試是必要的，但資料產品真D難測試

• 有太多外部依賴的單元測試
  處理資料的程式除了本身的處理邏輯之外，還需要資料源（例如 Database）以及資料出口（例如 Hadoop）。在做單元測試的時候，這些外部依賴基本上全部都需要 Mock，造成在單元測試時需要花很多心力去處理 Mock 的狀況。特別是當主程式需要根據讀到的資料做些除錯處理的時候，就還要另外 Mock 各種假的錯誤資料。

• 複雜的整合測試
  呈上，在整合測試階段就需要將這些外部依賴放進來一起測。如果只有單一資料來源可能還好搞定，之前有個 ETL 工具資料來源是 Kafka 和 PostgreSQL，還有用到 HBase 和 HDFS，這種整合測試做起來就很費功夫。

第五坑 對於資料產品特性不熟

根據資料產品的階層不同，會有不同的產品特性，這邊就先說明幾個比較常見的狀況：

• 需要應付大流量系統
  在開發階段通常只會用小量資料開發，如果只照測試資料的量級來開發、沒有考量真實資料大小的話，往往一上線爆炸後又要回來重新調整程式。

• 需要考量到未知/非法的資料來源
  通常開發用的範例資料都會給規格正確的資料，但實務上會碰到非常多不合法的資料，例如明明是 String，但是跑來了 Integer、明明規定資料長度只有 20 卻收到了 120，諸如此類的情況。有經驗的開發者在開發階段就會意識到這些問題並且提早做處理。但即便如此，還是有可能有沒有考量到的資料錯誤會發生。

• 太早的過度優化
  不管是程式開發還是訓練模型，都不能在早期做了過度的優化。程式的過度優化會平白增加程式複雜度，模型的過度優化會造成 Over fitting，特別是資料產品這種需要上線拿真資料做檢驗的，與其花時間優化，不如早點上線或早點引入正式資料來做驗證。