鲁迅说：嬉笑怒骂里充满了无奈和妥协。 小猿说：先生说的不对，在程序员的世界里，编写代码处处充满了无奈和妥协。
（一）改掉这些坏习惯，还怕写不出健壮的代码？
（二）改掉这些坏习惯，还怕写不出优雅的代码？
（三）改掉这些坏习惯，还怕写不出优雅的代码？
（四）改掉这些坏习惯，还怕写不出健壮的代码？
（五）改掉这些坏习惯，还怕写不出精简的代码？
上次讨论了一下如何借助注解来精简代码，代码修炼的系列分享，书接上篇，本次继续探讨一下：还有哪些奇淫技巧，能助力写出精简的代码？
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
寄语写最后
老子曰：有道无术，术尚可求也。有术无道，止于术。
庄子曰：以道驭术，术必成。离道之术，术必衰。
古人曰：上人用道，中人用术，下人用力。
小猿曰：管它什么道与术，能助力搬砖采石就足矣，因为我等采石之人心怀大教堂之愿景。
