标签：
怎样的代码才能作为产品代码提交到代码库中，使系统能够持续健康地成长？
第一级： 无语法错误，编译通过， 能够启动应用； 消除警告与错误；
第二级： 简洁清爽的排版，合理的命名， 一致的风格， 适宜必要的注释；
第三级： 能够处理正常情况下的功能实现，保证正常情况下的逻辑正确；
第四级： 能够处理不合法输入，给出错误提示；能够处理可能出现的错误和异常，输出容易排错的日志；
第五级： 使用相互协作良好的短小方法； 消除一个方法中含有大段逻辑的情形；
第六级： 编写的代码有比较完善的单元测试用例；对错误和异常进行了测试；
第七级： 避免常见的错误，比如 +-1、越界、空指针、 传值或引用错误、 变量未初始化为合适值、多条件下的逻辑与或非错误、死循环、修改全局变量；
第八级： 考虑基本的安全问题，比如SQL注入攻击、访问或操作权限限制、屏蔽敏感信息；
第九级： 如果涉及到性能，比如大量数据处理，选择合适的容器及算法，使性能保持在 O(nlogn) 或 O(n);
第十级： 使用合理的设计模式组织代码结构，消除重复，实现可扩展性；
第十一级： 开发时考虑后期维护，使错误情况的排查更加高效，从错误中恢复更加容易；
第十二级： 对共享可变的状态使用同步访问，使用并发类、线程池而不是原始的线程对象；
第十三级： 对于部分业务逻辑，使用合适的数据库事务和分布式锁同步；
我的观点是：
(1) 常见的逻辑，代码应当达到第八级， 才能作为产品代码提交到代码库中；
(2) 复杂的逻辑，代码应当达到第十三级，才能作为产品代码提交到代码库。
在提交代码之前， 对照该标准逐一核查， 满足指定级别的标准后提交。
第一级的说明： 代码中含有警告与错误， 应当细究其原因， 如果是 IDE 误报或允许存在， 使用适当方法消除它。
第二级的说明： 主要是可读性， 节省维护者的时间和精力。
第四级的说明： 如何使得日志的输出更适合于快速定位错误原因， 便于后续维护， 是值得下的开发功夫。
第五级的说明： 方法中含有大段逻辑， 会使得维护者耗费大量的脑细胞和时间精力去阅读和理解， 更难以测试， 更难以修改， 应当视为一种“谋杀其他程序员生命的行为”， 予以坚决杜绝。 如果不得不这样做， 必须使用空行将这些逻辑分割成多个逻辑段， 每个逻辑段辅以必要的注释， 说明每个步骤做了什么工作。
第六级的说明： 记得对错误和异常进行正确的测试。正常情况下， 对不应该抛出异常的测试。
第七级的说明： 修改全局变量不算是错误， 但是容易产生难以排查的错误。
第八级的说明： 密码等敏感信息不可出现在日志中； 若有风险性操作， 必须加以权限控制。
第九级的说明： 如果一个功能需要在多层循环遍历多个集合的数据， 不妨进行预处理， 利用预处理信息加速后续的处理。通常预处理都能使 O（n*n） 的算法复杂度降低到 O(n) 或 O(nlogn)。
第十一级的说明： 比如要做批量插入过保迁移实例功能。 如果若干实例在数据库中不存在，或者输入人员误输入， 该如何返回？
如果仅仅返回一个简单消息：Some are not exist，那么就必须让人来手工排查是哪些迁移实例不存在或误输入，这必定是个耗时耗力的情况；
因此，合理的返回是： 至少指出有哪些实例不存在，这样输入人员就只需要确认并修复这些不存在的实例即可。
预防胜于治疗。
产品代码的建议标准
标签：
原文地址：http://www.cnblogs.com/lovesqcc/p/4532501.html
