过了需求访谈後，在设计和开发阶段也有要注意的事项。

第一坑 资料不熟悉

当组织规模一大，设计资料产品的人可能需要从其他人的手伸认识资料，这种时候就会发生很多误解或沟通障碍。
以一间上市公司来说，资料仓储的表至少也有将近千个，光是要弄懂现有资料的特性就要花上许多时间，如果不同的资料有各自的所有者，就还要需要跟不同人去了解细节。

可能有人说有文件可以看啊，但就像前面说过，资料产品是「活」的，即便资料格式没有改变，但统计数值或概念还是会随着时间改变，这些改变也不会记录在文件中。

第二坑 孤独且漫长的探索过程

第二个坑也是满深的体会，过去待过的公司有大有小，资料团队少则三人、多到数十人都有。但不论团队人数多寡，资料分析师/科学家在产品开发的过程中，很难跟其他人协作。如果是一个比较长时间的调查资料（例如零售业调查），还会有些在这个产业资深的同事，可以指出资料中可能的问题或是提点分析的方向；但如果是比较新的资料应用，在探索资料的过程是有点难跟其他人分享，没有真正碰过资料的人很难知道资料的特色，只能根据分析师的结果进行讨论，中间处理资料的细节假设有问题也很难被发现。

第三坑 不良的开发习惯

很多制作资料产品的人，往往没有很丰富的软件开发经验，这些不良习惯可能会埋下往後在部署或是维运上的隐忧。这些习惯包括：

• 开发环境管理
  例如在自己电脑上装了 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，特别是资料产品这种需要上线拿真资料做检验的，与其花时间优化，不如早点上线或早点引入正式资料来做验证。