（六）改掉这些坏习惯，还怕写不出精简的代码？

鲁迅说：嬉笑怒骂里充满了无奈和妥协。 小猿说：先生说的不对，在程序员的世界里，编写代码处处充满了无奈和妥协。

（一）改掉这些坏习惯，还怕写不出健壮的代码？

（二）改掉这些坏习惯，还怕写不出优雅的代码？

（三）改掉这些坏习惯，还怕写不出优雅的代码？

（四）改掉这些坏习惯，还怕写不出健壮的代码？

（五）改掉这些坏习惯，还怕写不出精简的代码？

上次讨论了一下如何借助注解来精简代码，代码修炼的系列分享，书接上篇，本次继续探讨一下：还有哪些奇淫技巧，能助力写出精简的代码？

1

编码时：删除多余，才会更精简。

很多项目流转到你手中时，很多功能模块已废弃 ... ...

胆放大，心留细，一定要敢于动手去重构。少即是多，只有去除多余的代码，方能让代码更精简更完美。

精简代码时，能想到的事项如下：

• 多余的 Maven 依赖删除；
• 多余的配置信息删除；
• 废弃的 Module、API 、包、类、方法 删除；
• 多余的 常量、变量 删除；
• 多余的 导入、注解、注释、日志 删除；
• 多余的 TODO 删除；

举个栗子?

多余的 TODO，搞的后人不知所措。

再举个栗子??

由于功能下线，导致配置文件中依然维护多余的配置，每次上线还担心线上网络不通，解除后顾之忧，势必要去除多余的配置信息。

再举个栗子???

如截图示意，深入分析一下：

• 标注 3：接口中的方法默认都是 public 修饰，可以去除；
• 标注 2、4：子类都没有实现定义的方法，可以去除；
• 标注 1：子类没有实现该接口，则该接口可以去除。

当然，写出精简的代码，仁者见仁智者见智，主要与团队的开发规范有一定关系。

在项目研发中，还有哪些可以简化代码的地方呢？

• 利用反射进行对象赋值，可以简化大批量的赋值代码（计划：单独开篇去讨论）；
• 利用设计模式，例如工厂模式、模板方法模式，可以消除大量的重复代码，甚至 if else 语句；
• 利用属性拷贝工具，例如 BeanUtils，可以消除大量赋值代码（以往已经提及过）；
• 利用封装好的工具类，例如 StringUtils、CollectionUtils等可以简化大量的判断语句；
• 利用增强的 for 循环遍历集合和数组，会简化代码；
• 善于使用 return 关键字提前终止流程，会简化程序结构。

其实，还有很多，不一一枚举，下面简单看几张图，看看这些坏习惯，你是否犯过？

2

编码时：坏习惯，让代码显得冗长。

举个栗子?：

正解：采用 for-each 进行循环遍历集合，代码会相对简化一点。

以往分享过的栗子?：

正解：else 略显多余，可以去除。

心里话：提前终止语句，快速失败，会让代码简化不少，效率提升不少。

以往分享过的栗子?：

正解：在 return 前的判断，貌似略显多余，可以修改为。

心里话：在编码时，利用好 return 关键字，可以提前让函数返回，避免定义很多中间变量。

拿个项目中的栗子?：

正解：利用 return 关键字，可以适当调整如下。

心里话：在编码时，提前终止程序，会减少圈的复杂度，结构更清晰。

3

寄语写最后

老子曰：有道无术，术尚可求也。有术无道，止于术。

庄子曰：以道驭术，术必成。离道之术，术必衰。

古人曰：上人用道，中人用术，下人用力。

小猿曰：管它什么道与术，能助力搬砖采石就足矣，因为我等采石之人心怀大教堂之愿景。