一次线上翻车暴露了我工作方式的缺点

  最近给一个老项目修改一个核心功能，细节点比较多，原来就有这个功能，我需要改写这个功能，简单的来说就是写一套系统级规则，保存到数据库和es搜索引擎，然后使用的时候再到es搜索引擎里去查，结果更新到线上翻车了。
  为什么会翻车呢，我把原因分为外部原因和个人原因

• 外部原因：
    1. 环境不支持，测试这个功能需要的数据是由其他组的人提供，我们从一个渠道进来时携带的数据应该与其他组提供的数据有对应关系，测试环境没有这种对应关系不能测试，提供我们数据的人也不知道怎么配数据，但是说线上有完整数据可以测（为什么可以在生产环境测，因为我们是晚上11点多更新，那时候用户量少）。
    2. 团队意识不强，这个功能重心虽然在我们组，但也需要其他组的同事配合，结果晚上更新只有我们组的同事在公司，其他人都走了，凌晨出问题还得打电话沟通，结果问题还没有解决，最惨的是代码还不能回退。
    3. 原项目代码质量太差，代码里隐藏着坑，因为原来的功能有的地方没用到，所以这个坑很长时间没人填，还有很多地方不写注释，感觉有些东西没用却又不敢删，而且在9台服务器上找日志查问题也让人头痛。
• 个人原因：
    1. 做事不够细心，我忽略了某些功能上细节，思考问题有些片面，，虽然问题加两三行代码就好了，但也暴露了我做事马虎的缺点。
    2. 测试工作没做好，这个功能是我主导的，我除了完成开发工作之后，还应该在测试环境将每个地方都测通，虽然前面说过测试环境没有数据测试（前面说过原因），但是如果多想想办法，多找找人，说不定有能在测试环境测试的办法，总之不应该在生产环境测试。
    3. 没有考虑到新功能对历史数据的兼容，新功能改动有点大，表结构也发生了调整，相应es搜索引擎里的数据也发生改变，除了执行sql更新历史数据和刷新es索引，代码逻辑还得修改，但这不能在上线后才想到。

  针对以上原因，我应当做到下面几点
  1. 做事要有条理性，在功能开发之前如果时间够要做好详细设计工作，如果时间不够也应该理清每个功能点的业务线，每个细节的各异性，包括每个字段的处理和使用方式。
  2. 不要在生产测试，除非功能简单，代码改动范围小，撤回也方便
  3. 主导一个功能时，一定要将不同组的人串起来，哪一个环节不通，一定要想尽办法解决，哪怕不是自己的项目，也要多去想想别人的业务，因为别人的功能如果不是重心，他可能不太关心整体的项目完成情况。
  4. 对原业务进行修改，一定要考虑到历史数据，要多想想用户的使用场景。