2、多考虑一些边界值，临界情况一般是潜在隐患高发区；3、划清代码边界，考虑当前代码是否影响其它代码；4、考虑编码实现的效率是否拖累系统的整体性能；5、交给QA测试；6、上线后监控一段代码的日志输出，日志可以主要关注出现异常的情况，可以通过 AOP 将代码织入到代码中，通过出现异常后发生邮件或短信的形式通知开发人员，以便于快速确定问题。7、给出出现异常后的返回码即清晰的提示信息，即是因为什么导致出现的异常，可能不能精确定位为题，但是至少保证能够大大缩小排查问题的范围。8、编码要规范，强烈建议按照编码规范来执行。9、代码耦合度要低，内聚性要高。10、开发环境中的数据库改动都要做记录，比较好的方法是按日期，生成数据表变动的SQL，并且在上生产时一并提交给运维同时。11、数据库一定要做全量备份，增量备份依具体情况酌情选择。上线前一定要再全量备份数据库。12、不要在没有做充分论证前（至少要保证两个的参与并认可），停止生产上的任何服务；不要在未做充分论证前停止应用，不要在未充分论证前对数据库做任何的操作。13、拿到一个需求，先弄明白要做什么？要深刻的理解需求，这一点必须反复强调，如果能找出需求的逻辑漏洞会更好，可以与PD讨论并完善。14、吃透的需求后，要考虑采用什么技术实现，我们有没有这方面的经验，如果没有需求找哪些相关人员（有此经验的人，如果找不到有这方面经验的人，就可以报告领导，接下来的结果如何由领导决定，比如砍掉、比如采取其它方法）。15、吃透的需求，也知道的用什么技术实现，接下来就是考虑如何实现的问题，如何拆解需求成小的功能、拆解的粒度如何把控、工期长短的问题，是否影响其它业务的问题、性能问题、认真程度和细致问题（这点强调不过分，不服别理会！）。16、了解系统的现状，比如现状采用的技术是什么？处理业务的逻辑是什么？有什么优势？有什么需要改进的方面（系统已运行很久，一般不需要我们改变系统的整体思路，如果想改进，可以跟领导沟通，经同意后一点点改进、优化，切莫上来就操刀大干，那样血泪惨重，不信试试看）。
如何保证代码的有效性
