什么是好的代码？？---一点感想

什么是好的代码? 以下是我的一点感想，可能回答不完整，欢迎大家补充。

 

好的代码一定要有好的设计和规范来保证。仅以此篇来与项目组的同事们达成共识，在编程实现中考虑这些问题，并在代码检查中贯彻下去，这才是真正的目的。

 

这些条条框框大家说起来可能都懂，但是不是将这种思想真正的印记在脑子里，贯彻在行动上，产出的代码是不是能成为好的代码，这是一个素养问题，与程序员平时的

 

积累、思考有关。

 

(1)代码粒度合适

 

 每个类包含的方法合适，每个方法包含的代码量合适，而非满屏一个方法。切实的方法是对大的方法类，有一定的敏感性，书写短小精悍的代码。怎么创建粒度合适的代码呢？设计类从领域模型入手，设计方法考虑尽量考虑你的代码意图，小的意图产出小的方法，也可以规定一个方法不要超过一定行。

 

(2)高内聚，松耦合

 

这与(1)有些类似，但是只是粒度合适不一定就满足高内聚松耦合，这就要求从设计的高度，从业务的角度进行系统分析。可以采用测试驱动设计的思想，从是否能够单独单元测试来考虑是否可以将模块间的代码解耦。另外，如果方法过大，这个类就承担了过多的职责，一定不是高内聚的，违反单一职责原则。

 

 

(3)有一定的扩展性、灵活性

可以采用设计模式，解决这个问题，也可以从设计产品的角度，考虑如果是下个项目这部分代码能否以更小的修改代价进行。

 

(4)意图清晰

好的代码从命名开始。设计一个类命名需要清晰表达你的意图，采用设计模式需要清晰表达你的模式名称，比如***Strategy，不要写一些没有业务逻辑含义的命名，或者是太具有泛化、模糊含义的名称，或者是程序员语言的代码，比如getColumnModel，这在ext grid中命名是可以的，但是如果写在企业级应用的系统中，没有人能读懂到底要干什么。

 

(5)统一的规范

除了代码命名规范外，还有系统设计、处理的规范，比如异常处理的规范，是checkedexception还是checkedexception，异常在那一层处理，如何处理依赖？

如何处理事务，在哪一层处理事务？action层不要包括太多的业务逻辑，什么是代码坏味道。

 

前3项都是由好的设计来保证的，可见我们的设计直接影响了我们的代码质量，设计大多是由设计师或者技术经理完成，所以项目设计师或者技术经理对于控制代码质量是多么重要。

 

后记：

首先欢迎大家拍砖。我只是从正面角度回答了这个问题，那么从反面角度也可以提问:什么是不好的代码？哪些是代码的怀味，这些就要参考《重构》大作了。

 

写这篇文章是看到很多技术不错的同事忙乎于各种技术框架，编程语言，新的技术，但是可能忽视了程序员的一些基本素养；另一方面，大家各忙各的，一个团队却没有统一的共识，如果大家都一致认为这不是好的代码，这是代码坏味，每个人都能察觉并贯彻某些原则再好不过，统一共识对团队来讲是个起码的问题。

其次，也是希望大家都能重视代码质量（大家都说我重视啊，可是看看我们自己写的代码就知道自己可能在说谎，控制代码质量是一个团队行为，而不仅仅是个人责任），因为代码质量就意味着工程质量，差的工程质量就是增加成本。好的代码肯定bug少，修改bug容易，每个人都乐于修改、查看、学习别人的代码，而不是看到别人的代码就很头痛，别人看你的代码也很心烦，这样就造成代码在团队中不能共享。项目组如果能够产出好的代码，赏心悦目的代码，对维护人员是喜事，对我们自己那就是一种美了，编程之美。这个过程其实是让我们真正快乐的东西，毕竟你做了让别人觉得是有价值的东西，美的东西。