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

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

 

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

 

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

 

积累、思考有关。

 

(1)代码粒度合适

 

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

 

(2)高内聚，松耦合

 

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

 

 

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

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

 

(4)意图清晰

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

 

(5)统一的规范

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

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

 

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

 

后记：

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

 

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

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

 

 

评论

27 楼 seaendless 2010-06-30  

抛出异常的爱 写道

shuiguozheng 写道

85977328 写道

真正的高手，不是设计
而是去理解,维护并修改别人的代码

       恩，当菜鸟已经很久了，不想在当了。

理解别人的代码大多数时间是在慢性自杀.

异常大哥说的很对，自己在公司做事，接到别人的项目，要进行修改，可以是一打开却发现里面的密密麻麻的代码，却没有几行注释，真是让人看起来头都大了。
本人对于好的代码的理解，就是首先就是要让别人看的懂你写的东西，然后在谈别的

26 楼 hiblue 2010-06-28  

程序员虽然多, 但真正会写程序的很少, 好的代码更是难以见到,

25 楼 czpsailer 2010-06-28  

言之容，行之难

24 楼 kjj 2010-06-28  

85977328 写道

真正的高手，不是设计
而是去理解,维护并修改别人的代码

这算擦屁股高手........不是设计高手.......

23 楼 liwenjie 2010-06-28  

free_bird816 写道

设计是设计，代码是代码，两码事
好的设计不一定有好的代码，好的代码不一定是好的设计
单从代码讲，好的代码是简单的；效率的；注释清析的
而不是为了模式而模式的框框代码，为了设计而设计的冗余代码，为了进度而无注释的代码，为了····
唉！！

没有必要叹气，貌似看破红尘。 怎样产生好的代码？？可以发表意见嘛。好的代码是简单的；效率的；注释清析的，怎么达到呢？说都会说？关键是做。

我只是说好的设计容易产出好的代码，这不是绝对的关系，设计不好的代码会导致很多问题，比如粒度问题，职责不清，难道是好代码吗？而且除了设计之外，还有很多因素，我没有否认，请不要断章取义。

这些准则地球人都知道，所以很多人投了新手帖，还是那句话说都会说，除了探讨好代码的标准，其实从团队的角度，从可实施的角度，怎样产出好代码，这才是本帖要探讨的。请大家发表意见。

22 楼 抛出异常的爱 2010-06-28  

<div class="quote_title">select*from爱 写道</div>
<div class="quote_div">
<div class="quote_title">lib 写道</div>
<div class="quote_div">
<div class="quote_title">抛出异常的爱 写道</div>
<div class="quote_div">
<div class="quote_title">shuiguozheng 写道</div>
<div class="quote_div">
<div class="quote_title">85977328 写道</div>
<div class="quote_div">真正的高手，不是设计<br>而是去理解,维护并修改别人的代码</div>
<br>       恩，当菜鸟已经很久了，不想在当了。</div>
<br>理解别人的代码大多数时间是在慢性自杀.</div>
<p> </p>
<p><span style="color: #0000ff;"><strong>写出让机器读懂的代码很容易，写出让人读懂的代码很难！</strong></span></p>
</div>
<p>人定胜鸡（机器）</p>
</div>
<p>有个写headfirst 设计模式的人没活过53岁.</p>
<p>看到他的名子用黑框框住时</p>
<p>我心里一凉.</p>
<p>一直以为只有资本论这种书的作者会被黑框框着.</p>

21 楼 select*from爱 2010-06-28  

<div class="quote_title">lib 写道</div>
<div class="quote_div">
<div class="quote_title">抛出异常的爱 写道</div>
<div class="quote_div">
<div class="quote_title">shuiguozheng 写道</div>
<div class="quote_div">
<div class="quote_title">85977328 写道</div>
<div class="quote_div">真正的高手，不是设计<br>而是去理解,维护并修改别人的代码</div>
<br>       恩，当菜鸟已经很久了，不想在当了。</div>
<br>理解别人的代码大多数时间是在慢性自杀.</div>
<p> </p>
<p><span style="color: #0000ff;"><strong>写出让机器读懂的代码很容易，写出让人读懂的代码很难！</strong></span></p>
</div>
<p>人定胜鸡（机器）</p>

20 楼 lib 2010-06-28  

<div class="quote_title">抛出异常的爱 写道</div>
<div class="quote_div">
<div class="quote_title">shuiguozheng 写道</div>
<div class="quote_div">
<div class="quote_title">85977328 写道</div>
<div class="quote_div">真正的高手，不是设计<br>而是去理解,维护并修改别人的代码</div>
<br>       恩，当菜鸟已经很久了，不想在当了。</div>
<br>理解别人的代码大多数时间是在慢性自杀.</div>
<p> </p>
<p><span style="color: #0000ff;"><strong>写出让机器读懂的代码很容易，写出让人读懂的代码很难！</strong></span></p>

19 楼 抛出异常的爱 2010-06-28  

shuiguozheng 写道

85977328 写道

真正的高手，不是设计
而是去理解,维护并修改别人的代码

       恩，当菜鸟已经很久了，不想在当了。

理解别人的代码大多数时间是在慢性自杀.

18 楼 shuiguozheng 2010-06-28  

85977328 写道

真正的高手，不是设计
而是去理解,维护并修改别人的代码

       恩，当菜鸟已经很久了，不想在当了。

17 楼 edgar615 2010-06-28  

项目初期做的不好，我中途加入也没有想过修改
现在越做越烦咯
看着以前写的代码就想吐血
难道是我的水平比刚毕业的时候有了提高？

16 楼 7454103 2010-06-28  

个人愚见：
  代码的好坏应该建立在 保证效率和完成工作任务的基础上！
  没按时完成任务 很规范 很完善的代码 也是 一堆没用的字符！

15 楼 www1231985 2010-06-28  

这样的事情总是想起来容易做起来难
俺就是个懒人
要经常思考啊

14 楼 gulufather 2010-06-28  

代码是给人看的 不是给机器读的

13 楼 lym6520 2010-06-28  

代码结构的好坏很大程度上与是否有良好的项目结构和是否易维护有很大关系。
当项目经理把整个项目架构好后，各模块的代码质量就体现了复制各模块的开发员的代码质量如何了。

12 楼 select*from爱 2010-06-28  

心中无模式，代码皆模式

11 楼 free_bird816 2010-06-28  

设计是设计，代码是代码，两码事
好的设计不一定有好的代码，好的代码不一定是好的设计
单从代码讲，好的代码是简单的；效率的；注释清析的
而不是为了模式而模式的框框代码，为了设计而设计的冗余代码，为了进度而无注释的代码，为了····
唉！！

10 楼 wumingshi 2010-06-28  

可测试性是第一位的。

很难想象不可测试的代码具有可读性，可维护性。

9 楼 angel243fly 2010-06-27  

设计确实很重要，好的设计能大大控制住项目的质量和减少编码阶段的成本

8 楼 friendmine 2010-06-27  

对我来讲，首先考虑的是可读性，可维护性，其次才是可扩展性，
再下来是可测试性。
可读性，当然是注释，代码命名，正逻辑使用。
可维护性，主要是功能单一，接口参数清晰
可扩展性，就是楼主说的高内聚低偶合，再有就是整体代码是符合设计意图的。
可测试性，当然就是指比较方便进行单元测试。
不过说老实话，我最看重的是注释与代码命名。
其它的还好吧。