关于编码的若干最佳实践

昨天XX面试时，一道这样的问题难住了我，就是：在这么多年的编码中，说说自己的最佳实践。当时懵掉了，虽然看过很多敏捷开发、代码清洁之道、代码大全这些关于最佳实践的书，但却一条也说不出来。趁现在有时间，想想这个问题，总结一下自己的代码最佳实践。

 

1. 一致的代码格式。
2. 形成自己的工具类

开发时，为了减少代码量，多使用第三方的类库，如Apache Commons等，里面提供了简化操作的类。形成自己的工具类目标是简化代码开发，对一些通用功能进行封装。

1. 业务逻辑与技术实现相分离

如果一个函数或者一个类主要用来描述业务逻辑实现，那么最好不要在该方法有过多的技术细节实现。例如注册读者的功能，检查有效性、插入到数据库、发送邮件等这些算是业务逻辑。而针对每一个业务逻辑的技术实现细节最好和业务逻辑实现分开。这样使代码更加清晰。

1. 保持类和函数的短小，尽量提取可复用组件或者函数

类短小，可以控制类的单一功能和类的简单性。越简单越有助于重用。编写代码时，对每个代码段考虑这个代码段会重复出现吗？重复出现时，哪些参数需要变化？该怎么抽象这段代码呢？

1. 用设计模式去思考要解决的问题。而不是用流程去思考问题。
2. 优先使用组合，而非继承。继承意味着会给新建类带来新的方法，这些方法真的适用于这个新建的类吗？
3. 编写类时，应考虑这个类会不会在多线程下使用，如果在多线程环境下会不会有问题，如果有问题，该怎么解决。
4. 慎用StringBuffer/Vector/HashTable，这些类尽管在多线程下没有问题，但在单线程环境下可能效率不高。在单线程环境下，使用StringBuilder/ArrayList/HashMap.如果是多线程环境，考虑使用JCF中的同步类。
5. 变量名、函数名、类名表意。写出来的代码要达到不用注释就能看懂。
6. 命名时，避免使用类似ReaderInfo，ReaderClass这样的类名。Info和Class 是语义的重复，无需在命名时使用。
7. 边开发边重构。写代码时，如果发现有些不妥的地方，要及时重构和修改、测试。有时会想，先做完再重构，忘掉这种想法。这种想法不可取。越往后拖，越不易重构，越懒得重构。
8. 应考虑写出的代码可能面临的性能问题。使用这个类合适吗？有更简单更有效的代码改进吗？循环的结构修改一下会不会会提高效率，要不要定义临时变量或者状态字段存储处理结果以减少多次运算？……
9. 常见的类名前缀或者后缀：Simple***、Default***, ***ServiceProvider，***Utils, ***Templage, ***Template

, ***Model，***Factory, ****Adapter .接口在声明是多使用***able，表示实现类具有该能力，如Runable，Configurable，Customizable ，Imutable 等等。而实现类的声明多使用***Runner,****Configuration等名词结构。

 

目前暂时想到了这么多，以后想到了再补充。

1 流程都没想清楚，设计能对吗？

2 并不是优先使用组合，组合和继承适用的范围就不一样。


4 hashtable不是慎用

而是就不该用，不能用

5 这也不是什么好的意见，变量和方法名要简洁并且表意清楚，要不加注释就能看懂完全属于对代码可读性的错误理解，只要看着清楚就行，没必要那么极端

7 我个人不同意边开发边重构，重构确实是发生的随时随地，但是前提是重构目标清晰，并且有必要。边开发便重构会在重构的过程中打乱开发中的思路，影响功能的开发进度和完整性。
重构一书的副标题改善既有代码的设计。
问题是我遇到的很多开发流程1 没有既没有代码，2也没有设计。
在写代码的时候，代码还没出来，谈什么重构呢？
你甚至还不太清楚可能需要什么样结构。

第8条同样是个错误的实践，这个就不赘述了，翻一下旧帖子有很多的解释

至于6和第9条，我个人认为几乎没有什么意义，统一命名规范的最大价值在于其他的程序员在同样的规范规定下能立刻理解代码所进行的工作/具备的功能 和代码所使用的模式。

实际上这种命名规范在国内的代码生产中产生的作用很小。

大部门时间都是 一个已经离开的程序员折磨着新来的程序员，新来的程序员做好了准备折磨以后的程序员。

感谢LS回帖，并提出的宝贵的补充意见。话说我发了一天也没有人回帖。
对于边开发边重构，肯定有代码才会重构的。

建议参照JAVA的整洁之道。。

对于第7点我比较赞同，代码的重构应该在开发的时候进行，一般等你开发完了再来做重构经常会发现无从下手，更甚是懒得去重构

10， 一手好的代码，是需要时间积累的，多看多学多写
如果你回头看你的代码 发现 没有什么需要修改 说明 至少 已经 有一定境界了

但是离 牛人高手还太远，。。。共勉吧。。。

就是写一段代码，彻底删掉，重写，然后再删掉。在如此十几遍之后所得到的代码，通常比第一次要好得多
                 这是一个网络公司的老板说的，当然，在实际情况下，这种方式并不现实，但是每个周结束时花一点时间看看自己本周前面写的代码，并进行重构，个人觉得，还是比较可行的,就设计模式而言，我比较认同一句话，设计模式不是一蹴而就的，都是通过反复的重构，修改，随着业务越来越清晰而出来的，当然，先前好的设计是必须的，否则，重构无从谈起,呵呵，~~~，个人看法

  我不是很认同这句话，如果你隔了一段时间再回头去看自己的代码，发现没什么改的，不一定是到了一定的境界，而是你这段时间都没有进步，至少，在这方面，你都没有进步，我一直认为，检测自己近段时间是否有进步，最好的方法就是去看自己前面的代码，发现的问题越多，说明你进步也越大

这个观点我赞同。我也经常修改我博客的文章，随着学习的深入，发现一些谬误和不足

我觉的上面有人说Hashtable不能用，相当的奇怪，为何不能用？不能用的东西，为什么要搞出来。StringBuffer/Vector/HashTable 有效率问题，请问是什么效率问题？Vector是同步的，但我搞不懂StringBuffer，HashTable是什么效率问题，是指插入数据时很慢？可问题是我们不同情况有不同需求啊。可以说这种不能用的说话，我认为是根本不真正理解这些类的使用和原理的。