标签：重构 service 可读性 Optional 代码 既有 方法
读经典【1】重构：改善既有代码的设计
书评
五星好评。很实用。
最近读了重构原版书，同时也在使用其中的一些技巧来改善工作中的项目，自己改完代码会有成就感。
这本书改变了我原有的思想钢印：代码能成功跑起来就不要去动它。实际上，通过好的代码是通过不断重构和迭代实现的。
转念一想，我们喷别人写的代码是屎山，实际上自己的代码也不咋地，代码很重要的可读性就是问题，我们往往在自己写的时候不去考虑可读性，只靠问题的实现，这时我们头上戴着“实现”的帽子，实现了既有目标+自测后，代码就束之高阁了。当更多的历史代码无法维护时，才去考虑整体的代码重构。
如果进行不断的小步迭代，代码的可读性与可维护性就会不断提升。
我感觉代码就像是流水，是在不断变化的，而不是处于根据项目基线实现下的有限状态。在这种流水式的代码演进过程中，随着编码人员的理解不同，代码还会有back and forth，正如这本书中提到的大多数重构都是同时具有正向操作和反向操作的一样。
一种重构过程：
- 基于mvc模型，代码包含大量的 data(pojo) 类和 service，而这些 service 常常对代码进行流水账式的胶水操作。
- 需要添加新功能时，从service中寻找可复用的方法，没有则添加方法。
- 改善胶水代码，提高可读性。特别是长方法，根据单一职责原则，分解方法步骤。
- 面向对象程序设计。为 data 类添加功能，移动方法到对应的类中，相似的逻辑通过OOP进行封装和设计。
几个我不太认同的重构方法
- NullObject。空集合很适用，因为这个类天然自带”零元”, emptyCollection 就是 NullObject。默认值的填充使用Optional感觉更好，Optional 天然就是解决没有的，使用orElse, orElseGet, or等方法更好，此外还有 map, flatMap 等方法。况且Java 本来就有null这个关键字，就是用来表示没有的。null 和 Optional 以及@notnull等注解可以比较好地解决 NEP 的问题。用在二叉树上，null 表示没有值。用在unknown用户上，Optional 可以避免显式使用if else / 三元表达式，可读性更好，ofNullable(customer).orElse(unknown)。
- 方法内抛出异常。方法需要程序员关注超出方法签名的范围，有时需要查看注解才能得知异常。异常应该在方法签名上体现，使用 Result 类更好。
几个开箱即用的重构方法
如果你还没有看过原书，以下是我总结的几个可以快速上手的重构方法，不涉及OOP的设计，可以一试：
- Rename Method, Alt + Shift + R, 给方法起一个好名字。
- Replace Temp with Query, Alt + Shift + I (inline), 减少临时变量的使用。
- Extract Method, Alt + Shift + M, 对于长方法可以改为多个步骤的组合。
- 简化条件表达式，选中条件表达式，然后提取成方法。
- 代码中不可变的对象改为 final 或者值类型。
- 封装集合类，如返回 Collections.unmodifiableList(yourList);
标签：重构,service,可读性,Optional,代码,既有,方法 来源： https://www.cnblogs.com/dahua-dijkstra/p/16460298.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。