本文档为之前的开发期踩过的一些坑，并不完整，想到什么写什么，后续会继续补充

开发：

1.容灾设置。目前的平台运行依赖的底层组件有很多，包括MongoDB，spark，livy等等，后续随着平台的扩展可能引入的底层依赖会越来越多，之前的开发中遭遇过因代码逻辑不完善导致一台机器上的livy宕机整个系统都会崩掉，原因是代码逻辑巡检了每一台机器，当遇到宕机的机器时直接抛出异常导致请求挂掉，类似的事件应予以避免，当代码需要多个节点协同工作的时候应考虑到出现一台或多台节点宕机对平台功能及性能的影响

  1. UT覆盖。UT编写指南及规范参考链接,无论是前端还是后端，拥有一个好的UT覆盖率都是十分重要的，前端可以使用jtest进行编写，而后端可以使用junit里的@test注解进行编写，没有UT覆盖的代码极其容易在后续的维护中制造麻烦及制造BUG。UT应该与代码模块一同跟进，如本周项目组例会确定开发某一模块，下周验收的时候直接现场验证UT。同时，编写UT的时候也应当同时考虑错误反馈机制，以保证程序的鲁棒性
  2. 错误反馈。程序产生的错误主要分为两种
  • 内部错误。内部错误是用户无法察觉也无从规避的，如数据库宕机，程序BUG等，内部错误的主要应对方法为异常处理，以保证尽可能的在内部错误已经发生的情况下使系统能够最大程度的保持其功能
  • 用户操作错误。用户操作错误是可以通过用户的合法操作进行规避的（如输错密码等），但我们无法严格限定用户执行怎样怎样的操作，对于这一类错误应当在UI界面尽可能直观的通过提示框的形式反馈给用户其应该执行什么样的操作。

4.日志跟进。日志的作用主要为辅助运维使用。当BUG发生时能够随时根据规范化的日志以快速定位错误，解决问题。该部分主要针对后端，推荐使用slf4j的logger组件打印日志，日志项包括收到的请求，功能函数的输入和输出等，尽可能详尽，分不同级别进行打印（info，warn，error），普通输出信息定位为info，异常信息定义为warn，有可能导致系统宕机的分支定义为error.

5.模块设计与任务分配。模块设计文档要简洁易懂，描述出这个模块应该实现什么功能，需要什么输入，会获得什么输出，需要注重什么细节等等，任务分配书要明确给出需要完成什么任务，需要改动什么代码，期望的效果是什么，需要哪些参考资料。

运维：

1.CodeReview。建议项目组各个部分（前端，后端，算法）的负责同学能够对新加入项目的同学进行审核，控制代码质量（包括但不限于命名规范（可以用规约插件），格式化，注释编写，文档跟进，日志跟进，UT跟进等等。）

2.测试。上线运行后，新功能的测试需要在预发环境上运行，不要直接git pull到线上环境中，操作线上环境的权限应且只应保留在各部分的负责同学手中，需要新同学联调请使用预发环境。