今天让我们来谈谈代码吧。代码重要吗？当然，代码就是设计（Jack W.Reeves, 1992）；代码是最有价值的交付物。我们需要好代码吗？在给“好代码”下个定义之前，这个问题无法回答。那么，究竟什么是好代码？

看下面这段英文解释：

'Good code' is code that works, is bug free, and is readable and maintainable. Some organizations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' code analysis tools, etc. can be used to check for problems and enforce standards.

解释如下：

好的代码是代码运行正常、bug很少、并且具有可读性和可维护性。一些企业自己有所有开发人员都必需遵守的编码规范，但是对于什么样的代码是最好的每个人的都有自己的标准、或者有太多的或太少的编码规则。这有多种原则和标准，例如，McCable 的复杂度度量。的确使用过多的编码标准和规则可能降低生产率和创造性。“同行评审”或“同事检查”代码分析工具等，都能用来检查问题或坚持标准。

那么接下来我们深入介绍下，什么是好代码的标准呢，请看下面解释：

一、代码命名规范：

1、 package包名全部由小写的ASCII字母组成，用“.”分隔。在此项目中，所有的包均以“com.abc.ticket”开头。

2、 class 类名应当是名词，每个内部单词的头一个字母大写。应当使你的类名简单和具有说明性。用完整的英语单词或约定俗成的简写命名类名。
【示例】public class UserManager

3、 interface接口名应当是名词，每个内部单词的头一个字母大写。应当使你的接口名简单和具有说明性。用完整的英语单词或约定俗成的简写命名接口名。
【示例】interface TicketManagement

4、 Class 成员属性及变量的命名 (*) 变量名全部由字母组成，头一个字母小写，以后每个内部单词的头一个字母大写。变量名应该短而有意义。变量名的选择应该易于记忆。一个字符的变量名应避免，除非用于临时变量。通常临时变量名的命名规则为：i，j，k，m，n用于整数；c，d，e用于字符。

5、常量的命名，Java 里的常量，是用static final 修饰的，应该用全大写加下划线命名，并且尽量指出完整含义。
【示例】static final String SMTH_BBS="bbs.tsinghua.edu.cn";

6、数组的命名，数组应该总是用下面的形式来命名：byte[] buffer;

7、方法的参数和变量的命名规范一致，且应使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字。
【示例】setCounter(int size){ this.size = size; }

8、 方法命名(*)方法的命名应当使用动词，头一个字母小写，以后每个内部单词的头一个字母大写。在方法名的选择上应意义明确便于记忆。对于属性的存取方法，应使用getXXX()和setXXX()名称，以isXXX()，hasXXX()来命名返回值为boolean 类型的方法。

以上几条如果符合就算是好代码了吗？当然不是，这只是代码中最基本的命名规范而已，就算不符合最多就是代码不好看，没什么其他影响。

二、代码逻辑规范

1、需求、设计中的重点功能（结合需求/设计的评审产出）

2、代码格式校验
action/façade等系统入口是否有数据格式校验
需要存入数据库的数据字段是否有长度校验

3、分支/循环
if-else/switch是否处理了所有分支
分支的条件语句是否有“副作用”；即，条件语句是否会改变系统状态/数据等
循环边界是否覆盖了所有元素
是否有死循环等

4、异常处理
是否有“吃掉异常”的情况
是否记录了异常日志
如果二次抛出，是否有合理的异常层次/结构
如果内部处理，对异常的处理是否能保证后续代码正常运行

5、单元测试
是否有单元测试
单元测试是否自动化
单元测试是否能完整覆盖需求

6、 事务处理
事务范围是否合理；或者说，是否把不必要的操作放到了同一个事务中
事务传播方式是否合理（required，never，new等配置）

7、sql语句
sql语句是否正确
使用mybatis的动态语句时，是否有潜在的sql语法问题

8、第三方组件
使用Redis，RabbitMQ等组件，是否真的对组件完全了解，在使用的过程中是否正确执行了开启与关闭操作。

写到这里，可能会有不少读者认为，代码规范也就这些了吧，按照上面二类写完算是优秀的代码了吗？其实还是远远不够。

三、可读性，可维护性

曾经看过一段代码，一个method几千行代码，所有业务逻辑都揉在了一起。然后没有人愿意再维护了，修改一点就会引发不可预知的错误，代码又臭又长。在这种情况只能重构，于是我在部门内部推广二本书《代码整洁之道》和《重构-改善既有代码的设计》并且制订部门自己的开发风格，通过组织所有开发人员练习小项目的开发，使整个部门的开发风格整齐划一，不管是老同事还是新同事，都能够非常快速的上手，程序中依赖度降低，结构非常清晰。

四、性能瓶颈

在真实工作中，很多程序员其实在开发完程序后不去真正关注程序的性能和响应时间到底如何，凭的是以往开发经验在开发的过程中尽可能的去减少问题点。

这样就只能在生产环境中去验证性能问题了，实际这种做法风险较大，所带来的损失也是较大的，我们在开发完程序后，不仅要采用Junit或者JMock这样的工具进行业务功能自测，更重要是能够采用相应的工具和命令进行代码性能和响应时间的测试，在第一关就能够找出可能出现的一部分问题点，那么经常使用的工具和命令如下：
top，vmstat，pidstat，Hprof，Btrace，Dtrace等命令。

具体可以参考我以前写过的文章二篇：
http://blog.csdn.net/u013970991/article/details/52035153
http://blog.csdn.net/u013970991/article/details/52035133

五、代码容错

曾经有一个案例：
X同事在“统一配置管理系统“中将一个参数配置在里面，当参数进行修改的时候相应的程序会马上做出改变进行相应逻辑调整，可是另一个A同事在操作这个系统的时候配错了参数，这时候系统在生产环境中就开始报错，以致于应用程序崩溃，逻辑无法进行下去造成较严重的生产事故，最后恢复完参数故障时间已经进行了十几分钟。针对这个问题当时产生了争论，到底是配置人员的错，还是开发人员的错。

其实在我看来，到底是谁的问题暂且放在一边，关键是开发人员是否在写程序的过程中有没有多一丝的思考，多考虑一些问题点，程序员要时刻怀着一颗怀疑的心和敬畏的心对待自己写的程序，像上面的问题我们完全可以做一些异常捕获和默认设置，在出错的时候至少能够让应用程序跑下去而不能整体报错，让用户无法继续使用。

再说一个案例：
某部门在开发“统一配置管理系统”，使用的是Zookeeper组件，而且它的工作原理是当某节点改变的时候，主动去通知所注册的系统，但是有个前提是如果那些系统，有一部分没有得到通知，有一部分得到了通知该怎么办，比如某几个系统在通知的时候正好在重启，这时候zookeeper就不能通知到相应的系统，于是在使用该“统一配置管理系统”的时候，出了生产事故。

其实还应该再重复说一下，程序员应该持有怀疑的精神面对调用的系统和被调用的系统，不要把稳定、安全、可靠寄托于别人身上。

究竟怎样写代码才能算好代码？这是一个有争议的话题，每个人的理解可能都不同，关键是通过讨论这个话题制订一个符合自己部门要求的规范，这样有依据的代码才可能成为好的代码。

今天让我们来谈谈代码吧。代码重要吗？当然，代码就是设计（Jack W.Reeves, 1992）；代码是最有价值的交付物。我们需要好代码吗？在给“好代码”下个定义之前，这个问题无法回答。那么，究竟什么是好代码？

看下面这段英文解释：

'Good code' is code that works, is bug free, and is readable and maintainable. Some organizations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' code analysis tools, etc. can be used to check for problems and enforce standards.

解释如下：

好的代码是代码运行正常、bug很少、并且具有可读性和可维护性。一些企业自己有所有开发人员都必需遵守的编码规范，但是对于什么样的代码是最好的每个人的都有自己的标准、或者有太多的或太少的编码规则。这有多种原则和标准，例如，McCable 的复杂度度量。的确使用过多的编码标准和规则可能降低生产率和创造性。“同行评审”或“同事检查”代码分析工具等，都能用来检查问题或坚持标准。

那么接下来我们深入介绍下，什么是好代码的标准呢，请看下面解释：

一、代码命名规范：

1、 package包名全部由小写的ASCII字母组成，用“.”分隔。在此项目中，所有的包均以“com.abc.ticket”开头。

2、 class 类名应当是名词，每个内部单词的头一个字母大写。应当使你的类名简单和具有说明性。用完整的英语单词或约定俗成的简写命名类名。
【示例】public class UserManager

3、 interface接口名应当是名词，每个内部单词的头一个字母大写。应当使你的接口名简单和具有说明性。用完整的英语单词或约定俗成的简写命名接口名。
【示例】interface TicketManagement

4、 Class 成员属性及变量的命名 (*) 变量名全部由字母组成，头一个字母小写，以后每个内部单词的头一个字母大写。变量名应该短而有意义。变量名的选择应该易于记忆。一个字符的变量名应避免，除非用于临时变量。通常临时变量名的命名规则为：i，j，k，m，n用于整数；c，d，e用于字符。

5、常量的命名，Java 里的常量，是用static final 修饰的，应该用全大写加下划线命名，并且尽量指出完整含义。
【示例】static final String SMTH_BBS="bbs.tsinghua.edu.cn";

6、数组的命名，数组应该总是用下面的形式来命名：byte[] buffer;

7、方法的参数和变量的命名规范一致，且应使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字。
【示例】setCounter(int size){ this.size = size; }

8、 方法命名(*)方法的命名应当使用动词，头一个字母小写，以后每个内部单词的头一个字母大写。在方法名的选择上应意义明确便于记忆。对于属性的存取方法，应使用getXXX()和setXXX()名称，以isXXX()，hasXXX()来命名返回值为boolean 类型的方法。

以上几条如果符合就算是好代码了吗？当然不是，这只是代码中最基本的命名规范而已，就算不符合最多就是代码不好看，没什么其他影响。

二、代码逻辑规范

1、需求、设计中的重点功能（结合需求/设计的评审产出）

2、代码格式校验
action/façade等系统入口是否有数据格式校验
需要存入数据库的数据字段是否有长度校验

3、分支/循环
if-else/switch是否处理了所有分支
分支的条件语句是否有“副作用”；即，条件语句是否会改变系统状态/数据等
循环边界是否覆盖了所有元素
是否有死循环等

4、异常处理
是否有“吃掉异常”的情况
是否记录了异常日志
如果二次抛出，是否有合理的异常层次/结构
如果内部处理，对异常的处理是否能保证后续代码正常运行

5、单元测试
是否有单元测试
单元测试是否自动化
单元测试是否能完整覆盖需求

6、 事务处理
事务范围是否合理；或者说，是否把不必要的操作放到了同一个事务中
事务传播方式是否合理（required，never，new等配置）

7、sql语句
sql语句是否正确
使用mybatis的动态语句时，是否有潜在的sql语法问题

8、第三方组件
使用Redis，RabbitMQ等组件，是否真的对组件完全了解，在使用的过程中是否正确执行了开启与关闭操作。

写到这里，可能会有不少读者认为，代码规范也就这些了吧，按照上面二类写完算是优秀的代码了吗？其实还是远远不够。

三、可读性，可维护性

曾经看过一段代码，一个method几千行代码，所有业务逻辑都揉在了一起。然后没有人愿意再维护了，修改一点就会引发不可预知的错误，代码又臭又长。在这种情况只能重构，于是我在部门内部推广二本书《代码整洁之道》和《重构-改善既有代码的设计》并且制订部门自己的开发风格，通过组织所有开发人员练习小项目的开发，使整个部门的开发风格整齐划一，不管是老同事还是新同事，都能够非常快速的上手，程序中依赖度降低，结构非常清晰。

四、性能瓶颈

在真实工作中，很多程序员其实在开发完程序后不去真正关注程序的性能和响应时间到底如何，凭的是以往开发经验在开发的过程中尽可能的去减少问题点。

这样就只能在生产环境中去验证性能问题了，实际这种做法风险较大，所带来的损失也是较大的，我们在开发完程序后，不仅要采用Junit或者JMock这样的工具进行业务功能自测，更重要是能够采用相应的工具和命令进行代码性能和响应时间的测试，在第一关就能够找出可能出现的一部分问题点，那么经常使用的工具和命令如下：
top，vmstat，pidstat，Hprof，Btrace，Dtrace等命令。

具体可以参考我以前写过的文章二篇：
http://blog.csdn.net/u013970991/article/details/52035153
http://blog.csdn.net/u013970991/article/details/52035133

五、代码容错

曾经有一个案例：
X同事在“统一配置管理系统“中将一个参数配置在里面，当参数进行修改的时候相应的程序会马上做出改变进行相应逻辑调整，可是另一个A同事在操作这个系统的时候配错了参数，这时候系统在生产环境中就开始报错，以致于应用程序崩溃，逻辑无法进行下去造成较严重的生产事故，最后恢复完参数故障时间已经进行了十几分钟。针对这个问题当时产生了争论，到底是配置人员的错，还是开发人员的错。

其实在我看来，到底是谁的问题暂且放在一边，关键是开发人员是否在写程序的过程中有没有多一丝的思考，多考虑一些问题点，程序员要时刻怀着一颗怀疑的心和敬畏的心对待自己写的程序，像上面的问题我们完全可以做一些异常捕获和默认设置，在出错的时候至少能够让应用程序跑下去而不能整体报错，让用户无法继续使用。

再说一个案例：
某部门在开发“统一配置管理系统”，使用的是Zookeeper组件，而且它的工作原理是当某节点改变的时候，主动去通知所注册的系统，但是有个前提是如果那些系统，有一部分没有得到通知，有一部分得到了通知该怎么办，比如某几个系统在通知的时候正好在重启，这时候zookeeper就不能通知到相应的系统，于是在使用该“统一配置管理系统”的时候，出了生产事故。

其实还应该再重复说一下，程序员应该持有怀疑的精神面对调用的系统和被调用的系统，不要把稳定、安全、可靠寄托于别人身上。

究竟怎样写代码才能算好代码？这是一个有争议的话题，每个人的理解可能都不同，关键是通过讨论这个话题制订一个符合自己部门要求的规范，这样有依据的代码才可能成为好的代码。