将算法实现后，有可能并不会像我们以为的那样生效。比如代码中出现bug、计算公式写错、源数据异常、资源紧张导致程序运行失败，这些情况都会导致实际的结果与我们以为的不一样。
随着开发经验的增加，这些情况会越来越少。但经验不具有复制性，不能把别人的经验直接copy过来。这不是说别人的经验对你没用，而是说很多事情只有自己经历过，才知道是怎么回事。而且经验也不具有稳定性，总可能会出现意外遗漏某些东西。
解决这个问题最好的办法是列出可执行清单，原则上一份完整的清单上就能避免“事故”的出现。最能说明这点的地方就是机场，每架飞机起飞时，即使机组人员对流程很熟了，还是会对着清单一项项的检查。
最近五个月，我经历过几次“事故”，有自己造成的，也有别人引起的。为了减少再次掉进坑里的可能，我总结出了一些清单，这些清单就是算法真正实现的后勤保障。
我的清单如下：
- 源数据是否有过滤脏数据
- 每个功能函数是否都有测试用例
- 关键的中间数据是否有保存
- 是否在源数据以及最终输出算法结果增加了监控报警
任何算法实现的前提条件是有数据。数据中常出现两个问题，一是脏数据。比如商品id本应是数字，但部分商品id出现了其它字符。
二是数据信息量不对，即算法接收到的数据和实际的有偏差。数据传输环节越多，这种情况越有可能出现。
脏数据可能会导致程序报错然后退出，使算法无法更新。所以这里要有三层保障，一是过滤脏数据，这能保证算法正常更新。脏数据总可能会出现，所以第二层保障是增加监控报警，当算法输出的结果文件没有更新时发送报警信息。
过滤了脏数据虽然能保证算法正常更新，但要是脏数据过多怎么办呢？比如由于技术故障导致大面积的商品id出现问题，在这种情况下算法更新也许还会导致更严重的后果。
数据信息量不对这件事就难办了，特别是正处在发展期的公司。往往是出现了问题之后才有可能去检查数据在传输过程或自己代码中的过滤条件导致信息量不对。为了让检查能快速，所以可能提前保存关键的中间数据。比如开法个性化推荐算法时，商品或用户的汇总数据。
解决完数据的问题之后就是要保证代码逻辑正确了。我曾经在开发一个推荐算法时，把排序值的计算公式给改错了，等线上出问题了用git查看记录才发现这个问题。
而解决逻辑问题最有效的办法就是写测试用例，正常情况下每一个函数应该至少准备一个测试用例。这样做的前提是你开发的算法代码不是只有一个主函数，主函数中的每个功能尽可能的写成函数的形式，这样通过主函数就能了解整个算法的逻辑，而测试用例能确保每个功能函数是按正确的想法实现的。
由于数据是大家共用的，所以很多数据的问题，即使自己没发现，别的同事也能发现并修正。但代码逻辑是否正确却只能靠开发者自己。所以是需要开发者花大精力去保障逻辑的正确性的。像上面说的那种错误，其实只需要一个测试用例就能找出问题所在。
清单也是需要不断完善的，每次发现新的问题时想办法解决，并把它加入清单。只有这样，清单才能不断完善，发挥其作用。
