From 1da18aa1a128d031e70a880d6f2849b48e2c1582 Mon Sep 17 00:00:00 2001 From: CyC2018 <1029579233@qq.com> Date: Sun, 4 Mar 2018 14:57:28 +0800 Subject: [PATCH] auto commit --- notes/重构.md | 60 +++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 53 insertions(+), 7 deletions(-) diff --git a/notes/重构.md b/notes/重构.md index 4e3fd6a9..69806117 100644 --- a/notes/重构.md +++ b/notes/重构.md @@ -1,6 +1,14 @@ * [第一章 第一个案例](#第一章-第一个案例) * [第二章 重构原则](#第二章-重构原则) + * [定义](#定义) + * [为何重构](#为何重构) + * [三次法则](#三次法则) + * [间接层与重构](#间接层与重构) + * [修改接口](#修改接口) + * [何时不该重构](#何时不该重构) + * [重构与设计](#重构与设计) + * [重构与性能](#重构与性能) * [第三章 代码的坏味道](#第三章-代码的坏味道) * [1. Duplicated Code（重复代码）](#1-duplicated-code重复代码) * [2. Long Method（过长函数）](#2-long-method过长函数) @@ -168,21 +176,59 @@ double getTotalCharge() { # 第二章 重构原则 +## 定义 + 重构是对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。 -重构的好处：改进软件设计；使软件更容易理解；帮助找到 Bug；提高编程速度。 +## 为何重构 -三次法则：第一次做某件事时只管去做；第二次做类似事情时可以去做；第三次再做类似的事，就应该重构。 +- 改进软件设计 +- 使软件更容易理解 +- 帮助找到 Bug +- 提高编程速度 -间接层与重构：计算机科学中的很多问题可以通过增加一个间接层来解决，间接层具有以下价值：允许逻辑共享；分开解释意图和实现；隔离变化；封装条件逻辑。重构可以理解为在适当的位置插入间接层以及在不需要时移除间接层。 +## 三次法则 -修改接口：可以保留旧接口，让旧接口去调用新接口，并且使用 Java 提供的 @deprecation 将旧接口标记为弃用。除非真有必要，不要发布接口，并且不要过早发布接口。 +第一次做某件事时只管去做；第二次做类似事情时可以去做；第三次再做类似的事，就应该重构。 -当现有代码过于混乱时，应当重写而不是重构。一个折中的办法是，将代码封装成一个个组件，然后对各个组件做重写或者重构的决定。 +## 间接层与重构 -软件开发无法预先设计，因为开发过程有很多变化发生，在最开始不可能都把所有情况考虑进去。重构可以简化设计，重构在一个简单的设计上进行修修改改，当变化发生时，以一种灵活的方式去应对变化，进而带来更好的设计。 +计算机科学中的很多问题可以通过增加一个间接层来解决，间接层具有以下价值： -为了软代码更容易理解，重构可能会导致性能减低。在编写代码时，不用对性能过多关注，只有在最后性能优化阶段再考虑性能问题。应当只关注关键代码的性能，因为只有一小部分的代码是关键代码。 +- 允许逻辑共享 +- 分开解释意图和实现 +- 隔离变化 +- 封装条件逻辑。 + +重构可以理解为在适当的位置插入间接层以及在不需要时移除间接层。 + +## 修改接口 + +如果重构手法改变了已发布的接口，就必须维护新旧两个接口。 + +可以保留旧接口，让旧接口去调用新接口，并且使用 Java 提供的 @deprecation 将旧接口标记为弃用。 + +可见修改接口特别麻烦，因此除非真有必要，否则不要发布接口，并且不要过早发布接口。 + +## 何时不该重构 + +当现有代码过于混乱时，应当重写而不是重构。 + +一个折中的办法是，将代码封装成一个个组件，然后对各个组件做重写或者重构的决定。 + +## 重构与设计 + +软件开发无法预先设计，因为开发过程有很多变化发生，在最开始不可能都把所有情况考虑进去。 + +重构可以简化设计，重构在一个简单的设计上进行修修改改，当变化发生时，以一种灵活的方式去应对变化，进而带来更好的设计。 + +## 重构与性能 + +为了软代码更容易理解，重构可能会导致性能减低。 + +在编写代码时，不用对性能过多关注，只有在最后性能优化阶段再考虑性能问题。 + +应当只关注关键代码的性能，因为只有一小部分的代码是关键代码。 # 第三章 代码的坏味道