标签：数据表 选择 问题 短信 系统 改变 返回 优势 服务
1、充分的自测，各种场景都要测试到，入参与出参结果与计算要保持一致；
2、多考虑一些边界值，临界情况一般是潜在隐患高发区；
3、划清代码边界，考虑当前代码是否影响其它代码；
4、考虑编码实现的效率是否拖累系统的整体性能；
5、交给QA测试；
6、上线后监控一段代码的日志输出，日志可以主要关注出现异常的情况，可以通过 AOP 将代码织入到代码中，通过出现异常后发生邮件或短信的形式通知开发人员，以便于快速确定问题。
7、给出出现异常后的返回码即清晰的提示信息，即是因为什么导致出现的异常，可能不能精确定位为题，但是至少保证能够大大缩小排查问题的范围。
8、编码要规范，强烈建议按照编码规范来执行。
9、代码耦合度要低，内聚性要高。
10、开发环境中的数据库改动都要做记录，比较好的方法是按日期，生成数据表变动的SQL，并且在上生产时一并提交给运维同时。
11、数据库一定要做全量备份，增量备份依具体情况酌情选择。上线前一定要再全量备份数据库。
12、不要在没有做充分论证前（至少要保证两个的参与并认可），停止生产上的任何服务；不要在未做充分论证前停止应用，不要在未充分论证前对数据库做任何的操作。
13、拿到一个需求，先弄明白要做什么？要深刻的理解需求，这一点必须反复强调，如果能找出需求的逻辑漏洞会更好，可以与PD讨论并完善。
14、吃透的需求后，要考虑采用什么技术实现，我们有没有这方面的经验，如果没有需求找哪些相关人员（有此经验的人，如果找不到有这方面经验的人，就可以报告领导，接下来的结果如何由领导决定，比如砍掉、比如采取其它方法）。
15、吃透的需求，也知道的用什么技术实现，接下来就是考虑如何实现的问题，如何拆解需求成小的功能、拆解的粒度如何把控、工期长短的问题，是否影响其它业务的问题、性能问题、认真程度和细致问题（这点强调不过分，不服别理会！）。
16、了解系统的现状，比如现状采用的技术是什么？处理业务的逻辑是什么？有什么优势？有什么需要改进的方面（系统已运行很久，一般不需要我们改变系统的整体思路，如果想改进，可以跟领导沟通，经同意后一点点改进、优化，切莫上来就操刀大干，那样血泪惨重，不信试试看）。
17、多维度把握我业务需求，从而降低业务的复杂度。
18、做功能的很重要的一个参考就是功能十分自闭环。
19、一个功能需求如果太大，在规定的工期内无法完成，可以跟领导、PD沟通，分期做。
20、确定完成当前功能的依赖项，即要完成当前功能，需要我们先完成哪些功能，也要考虑完成此功能可能会出现的异常情况，如果处理这些异常情况。
21、在开发一个功能时，一一列出这个功能拆解出来的小功能，并在每完成一个小功能后将其划掉，这样可以提振信心，提升士气，同时防止遗漏。
22、避免客户端做接口应该做的事情，比如本应该接口做的for循环，由客户端来做了，性能会很差的。
23、避免暴露无用的、未经测试的接口，即遵循接口暴露最小原则。
24、线上出现问题的功能非特殊情况要先关闭，一般出现问题都是新上线的，或上线时间不会太长的，用户量自然不会多，特殊情况特殊处理，这里只考虑一般情况。
25、优化执行慢的SQL、监控CPU、内存、磁盘、网络的使用情况。
26、做好准备面对压力的心里准备。
27、复杂问题拆解成小问题，小问题再拆解成CURD，分步骤，分批次，一点点解决掉，万不可惊慌失措。
标签：数据表 选择 问题 短信 系统 改变 返回 优势 服务
原文地址：http://www.cnblogs.com/hapday/p/6239334.html
