抽象是架构思维里面的一个重点，其中包括两个层面的内容：一个是常说的归纳方法，即各种类似场景的实现太多了，自然就归纳了一种规则或方法出来供以后的设计用；另一个是抽象，它更加重要，即将非类似场景中的共性内容也总结出来，进一步抽象为类似的东西，以更加方便地适应各种变化。

结构化是一种从框架到细节的思维方式，强调在分析问题的过程中，不先入为主，不马上陷入细节。结构化也被称为表格化的思维结构，强调结构和逻辑，通过结构的完整和逻辑的严密来保证结果的正确。结构化的核心在于对问题进行正确界定的基础上（以终为始），对问题的构成要素进行合理分类，并对其中的重点环节进行分析（要事第一）。

结构化的原则结构化的原则如下。

◎ 以终为始。

◎ 知道做这件事情的目标是什么。

◎ 根据这个目标倒推需要完成哪些工作和任务。

◎ 做任何一件事情都必须有一个目标，才能在分析论证过程中得到预期的结果。

◎ 不要先入为主，避免陷入细节。

◎ 必须对各种观点进行分组，分组后的思想观点在经过不同层次的抽象后构成金字塔。

◎ 分 类 原 则 MECE （ Mutually Exclusive CollectivelyExhaustive，相互独立、完全穷尽）。

◎ 相互之间具有排他性，整体而言毫无遗漏。

简单地说，结构化的原则就是不重叠、不遗漏。

结构化分析工具

结构化工具主要有如下几种。

◎ 逻辑树：又叫作问题树、演绎树或分解树等，是将所有问题的子问题都分层罗列，从最高层开始逐步向下扩展。

◎ 议题树：将问题分解成多个利于操作的小块并分别进行处理，

在解决问题的早期还没有足够形成假设的基础。◎ 假设树：先给出解决问题的假设方案，再举出所需的充足原因来验证或推翻该假设，较早集中于潜在的问题，加快解决问题的进程，对情况有足够的了解，能提出合理的假设方案。

◎ 是否树：列出关键问题，使用“是”和“否”来回答，按照需要采取相应行动的逻辑顺序来排列，确认对目前要做的决定有关键意义的问题，应该对事务及其结构有良好的理解，并可作为沟通工具。

◎ 二维表格。

◎ 80/20法则：80/20法则是分析式的方法。80/20分析法用于让人注意到造成某种状况的关键原因，也就是找到那些导致80%产出的20%投入。

结构化思维的7个环节

结构化思维的7个环节如下。

◎ Who：谁来做？

◎ What：内容是什么、做什么？

◎ When：什么时候做？

◎ Where：在哪里做？

◎ Why：为什么做这件事情？

◎ How：怎么做？

◎ How Much：用多少时间和其他资源？

迭代思维是我们在架构思考中需要考虑的另一个内容。没有最优的架构，只有不断进化的架构和最适合的架构，因此架构本身也在随着业务需求的变化不断迭代和演化，而不是追求用最新的技术一步到位。

架构设计往往发生在需求的细节尚未完成时。因此，随着项目的进行，需求还可能细化、变更。原先的架构肯定会有不足或错误的地方。

借用一句名言，“凡事预则立，不预则废”，在软件设计初期，投入精力进行架构设计是很有必要的，这个架构是我们在后续的设计、编码过程中依赖的基础。我们应用迭代方法的最大目的就是稳步地改进软件架构。

软件架构的改进在软件开发过程中会经历一个振荡期，这个振荡期可能横跨了数个迭代周期，其间的架构设计将会经历剧烈的变化，但最后一定会趋向于平稳。

如果架构师创造的功能无法正好迎合需求或实现业务目标或不必要的特征，则会出现过度设计的现象，这一般是因为不清楚项目需求或不确定架构的性能。为了避免出现过度设计的现象，我们需要使需求透明化。过度设计的迹象并不总是显而易见的，但识别这些迹象对节省时间和降低成本非常重要。不需要做超出需求的设计，不需要假设不存在的极端条件做系统架构设计。

过度设计的特征如下。

◎ 超高强度。

◎ 终极性能。

◎ 重新设计。◎ 过度合理。

过度设计的影响如下。

◎ 开发时间和成本。每个新功能都必须经过设计、研发、测试的步骤。这样大大增加了人力和时间成本，导致项目的交付时间延长。

◎ 维护成本。过于复杂的架构设计都会导致各种问题，增加了维护成本，并且让整个系统的维护过程变得复杂。

过度设计的原因如下。

◎ 需求透明度。如果在架构设计之初并未完全理解需求方提出的需求，或遗漏了关键的需求，出现误解的可能性就会大大提高，从而导致架构设计过度。

◎ 架构性能未知。高估了产品的市场预期。

作者：大数据架构师 来源：https://www.toutiao.com/a6907218379338285580/