it三大定律
体系结构决策的问题在于它们会影响整个系统，并且/或者您通常需要在开发过程的早期就将其制定出来。 如果您在几个月后更改该决定，则需要付出很多努力。 从经济角度来看，架构决策通常是不可撤销的。 好的架构可以使架构师做出较迟的决策，而不会对工作和成本产生明显的影响。 让我们记录下来。
法则1：好的架构是使建筑师能够做出最少的，不可撤销的决定的架构。
为了最大程度地减少不可撤销的决策，系统需要对变化做出响应。 我从软件开发项目中学到了一个重要的教训：除了改变，没有什么是永久的。 客户改变了他对需求的看法。 利益相关者改变他们对重要事物的看法。 人们加入并离开项目团队。 改变本身并不会改变的事实使我想到了良好架构的第二条规则，即：
法则2：要使决定可撤销，您需要设计灵活性。
这是最具挑衅性的声明，我在这里进行有争议的讨论。 原因是灵活性引入了抽象需求。 抽象使用简化策略，其中以前的具体细节含糊不清，含糊不清或不确定（来自Wikipedia ）。 这种简化过程并不总是容易做到的，特别是对于其他人而言，遵循的过程并不总是那么简单。 “使某些事情易于更改会使整个系统更加复杂，而使所有内容易于更改会使整个系统非常复杂。 复杂性使软件难以更改。” 来自M. Fowler的文章 ）是构建良好软件体系结构的核心问题：开发易于更改但同时易于理解的软件。 有几种概念试图解决这个矛盾问题： 设计模式和面向对象的设计原则 。 多态性，松散耦合和高内聚性是我的灵活性促成因素。
法则3：要利用灵活性，就需要无情地重构。
灵活性本身并不是目的。 您需要积极利用灵活的设计。 如果有什么变化，并且使先前的设计或体系结构决策过时，则需要进入代码并更改软件。 否则，构建灵活软件的工作将毫无用处，技术债务可能会导致延迟交付和维护噩梦。 您对代码库采取了严格的措施，这一事实要求您不断地反馈有关软件质量的信息。 因此，为了能够进行重构，必须有足够数量的自动化测试来覆盖代码库。 在理想情况下，所有内容都将集成到连续集成环境中，以接收有关代码库运行状况的永久反馈。
it三大定律
