通过重构得到更深层的理解
通过重构得到更深层的理解是一个涉及很多方面的过程。有三件事情是必须要关注的:
- 以领域为本;
- 用一种不同的方式来看待事物;
- 始终坚持与领域专家对话。
开始重构
获得深层理解的重构可能出现在很多方面。一开始有可能是为了解决代码中的问题------一段复杂或笨拙的代码。但开发人员并没有使用(代码重构所提供的)标准的代码转换，相反，他们认为问题的根源在于领域模型。或许是领域中缺少一个概念，或许是某个关系发生了错误。与传统重构观点不同的是，即使在代码看上去很整洁的时候也可能需要重构，原因是模型的语言没有与领域专家保持一致，或者新需求不能被自然地添加到模型中。重构的原因也可能来自 学习:当开发人员通过学习获得了更深刻的理解，从而发现了一个得到更清晰或更有用的模型的机会。如何找到问题的病灶往往是最难和最不确定的部分。在这之后，开发人员就可以系统地找出新模型的元素。他们可以与同事和领域专家一起进行头脑风暴，也可以充分利用那些已经对知识 做了系统性总结的分析模式或设计模式。
探索团队
不管问题的根源是什么，下一步都是要找到一种能够使模型表达变得更清楚和更自然的改进方案。这可能只需要做一些简单、明显的修改，只需几小时即可完成。在这种情况下，所做的修改类似于传统重构。但寻找新模型可能需要更多时间，而且需要更多人参与。
修改的发起者会挑选几位开发人员一起工作，这些开发人员应该擅长思考该类问题，了解领域，或者掌握深厚的建模技巧。如果涉及一些难以捉摸的问题，他们还要请一位领域专家加入。 这个由4~5人组成的小组会到会议室或咖啡厅进行头脑风暴，时间为半小时至一个半小时。在这个过程中，他们画一些UML草图，并试着用对象来走查场景。他们必须保证主题专家(subject matter expert)能够理解模型并认为模型有用。当发现了一些令他们满意的新思路后，他们就回去编码，或者决定再多考虑几天，先回去做点别的事情。几天之后，这个小组再次碰头，重复上面的过程。这时，他们已经对前几天的想法有了更深入的理解，因此更加自信了，并且得出了一些结论。他们回到计算机前，开始对新设计进行编码。
要想保证这个过程的效率，需要注意几个关键事项。
- 自主决定。
可以随时组成一个小的团队来研究某个设计问题。这个团队只工作几天，然后就可以解散了。这种团队没有长期存在的必要，也不必有复杂的组织结构。
- 注意范围和休息。
在几天内召开两三次短会就应该能够产生一个值得尝试的设计。工作拖得太长并没什么好处。如果讨论毫无进展，可能是一次讨论的内容太多了。选一个较小的设计方面，集中讨论它。
- 练习使用UBIQUITOUS LANGUAGE。
让其他团队成员(特别是主题专家)参与头脑风暴会议是练习和精化UBIQUITOUS LANGUAGE的好机会。这样，原来的开发人员可以得到更完善的UBIQUITOUS LANGUAGE，并反映到编码中。成熟的头脑风暴是灵活机动、不拘泥于形式的，而且具有令人难以臵信的高效率.
重构的时机
持续重构渐渐被认为是一种"最佳实践"，但大部分项目团队仍然对它抱有很大的戒心。人们虽然看到了修改代码会有风险，还要花费开发时间，但却不容易看到维持一个拙劣设计也有风险，而且迁就这种设计也要付出代价。想要重构的开发人员往往被要求证明其重构的合理性。虽然这看似合理，但这使得一个本来就很难进行的工作变得几乎不可能完成，而且会限制重构的进行(或者人们只能暗地里进行)。软件开发并不是一个可以完全预料到后果的过程，人们无法准确地计算出某个修改会带来哪些好处，或者是不做某个修改会付出多大代价。
在探索领域的过程中、在培训开发人员的过程中，以及在开发人员与领域专家进行思想交流的过程中，必须始终坚持把"通过重构得到更深层理解"作为这些工作的一部分。因此，当发生以下情况时，就应该进行重构了:
- 设计没有表达出团队对领域的最新理解;
- 重要的概念被隐藏在设计中了(而且你已经发现了把它们呈现出来的方法);
- 发现了一个能令某个重要的设计部分变得更灵活的机会。
我们虽然应该有这样一种积极的态度，但并不意味着可以随随便便做任何修改。不要引入一些只顾炫耀技术能力而没有解决领域核心问题的"柔性设计"。无论一个"更深层的模型"看起来有多好，如果你不能说服领域专家们去使用它，那么就不要引入它。万事都不是绝对的，但如果某个重构对我们有利，那么不妨在这个方向上大胆前进。
通过重构得到更深层理解是一个持续不断的过程。人们发现一些隐含的概念，并把它们明确地表示出来。有些设计部分变得更具有柔性，或许还采用了声明式的风格。开发工作一下子到了突破的边缘，然后开发人员跨越这条界线，得到了一个更深层的模型，接下来又重新开始了稳步的改进过程。