开发反思与总结

1、敬畏生产环境，提高代码质量及程序健壮性。

围绕此次生产事件，看了相关事故分析后，我有以下几点想法和建议：

首先从开发人员自身出发，是什么原因导致此次线上问题，开发技术水平？开发时间？历史问题？重视程度？

以此次来看，我认为开发水平是次要的，更多的是时间、历史、以及重视程度的互相作用。

开发时间的紧张可能会导致相关流程的缩减, 对于代码架构历史的不了解，以及业务的重要程度的不清晰，会导致对需求或代码变动带来影响的重视程度不够。

在这种情况下,开发人员主观的东西可能很少, 换了别人可能也会如此，bug想完全杜绝几乎不可能， 因此在这种情况下我想的是，是否可以从制度入手，来尽量规避问题：

1.1、 在每次需求来的时候，建立一个 需求改动影响或接口错误影响的评级机制, 对本次需求涉及的旧接口或新开发的都进行评定，有最为熟悉该模块的同事来参与评定和制定，

在具体开发前 必须以文档的形式落实在wiki上。

1.2、 根据制定需求评定及接口评级, 在自测、代码review以及正式测试时，有区分和重点的对接口进行测试， 如评级影响为2级以上的，至少两人参与评审, 并留下评审记录, 能够问责追溯。

1.3、 放缓节奏，严格落实以上流程，我们崇尚快速出成果，但像这种风险较高的接口 ，必须衡量 “快" 跟 出了问题的风险谁更重要，必须慢，慢就是快。

1.4、总结：建立需求风险、接口风险评级制度，重点内容放慢速度，严格落实。

2、做好核心监控，防患于未然。

2.1、 承接上一点，这个就不仅是做需求了，系统的梳理所有的接口故障风险等级、建立相关文档。

根据风险等级对重点接口 做好监控。

3、关注系统状态，节假日也得够及时响应、解决问题。

如果没有特别的职责划分或者补偿，没人愿意在休息日正常进行工作的。而且有时候，在节假日，确实有私人的事情，短时间内无法处理问题。这是客观情况。当然，

对于自身态度确实有问题的，需要进行相应的谈心。但从事情的处理来看，给我们的启示是，不要让一个人负责一个模块，人手充足的情况下，至少两人负责一个模块。

人手不够，也应该交叉着管，让一个人既做这个模块，也熟悉另外一个。这样出了问题，当一个人是在脱不开身，还有另外一个人具有处理能力。极力避免全部鸡蛋放一个篮子。