软件架构设计运用的思维模式

Posted 2021-04-02 记在这里

1、四种思维模式

设计软件系统需要我们从不同的角度考虑架构。设计思维模式（简称思维模式）可以帮助我们在合适的时机关注合适的细节。

    思维模式分为四种：理解、探索、展示、评估。每一种思维模式都有配套的方法。设计架构时，我们先选择一种思维模式，再运用配套的方法发现架构，然后不断重复这个过程。

（1） 理解问题(Understand the Problem)

    这种思维模式要求我们主动从利益相关方那里获取信息，清晰地描述问题。理解对方的需求其实就是站在对方的角度考虑问题。为了理解问题，我们必须了解所有与系统有关的人以及他们需要什么。

    为了理解问题，我们既需要研究利益相关方关心的业务目标和质量属性，也要掌握开发团队自身的工作风格，这样才能把握设计的轻重缓急，取舍利弊。

（2）探索问题(Explore Ideas)

    现在有一种流行的风气，将设计思维完全当做是头脑风暴。头脑风暴很好，但它只是探索想法的一种手段。我们所有的探索，是指形成一系列设计概念，确定解决问题的工程方法。

    探索软件架构意味着尝试各种结构的组合，直到找到最能提升目标质量属性的那种组合。为了找到最佳组件，需要研究大量的模式、技术、开发方法。这种思维模式不仅能在架构规划时发挥作用，在与利益相关方协作时也能派上用场。

（3）展示想法(Reason about Quality Attributes(and Other System Properties))

    正如设计思维第四条原则“化虚为实”强调的那样，如果无法让他们理解和接受你的想法，再棒的创意也无法产生价值。展示想法不仅是为了分享，也是为了检验合理性。这种思维模式强调将脑海中的设计理念转化为有形物品。

    最常见的展示方式是制作模型，除了线框图，你还可以制作原型、编写文档、展示数据，等等。

     展示想法对于协商和制订计划非常重要。开发系统时，我们也要设法展示架构（比如通过组件代码展示架构中的模块架构）。这种思维模式是让团队摆脱“分析瘫痪”的绝佳方式。

（4）评估适用性(Evaluate Fit)

    我们怎么知道某个设计决策是否真能解决问题呢？评估可以帮助我们发现设计决策是否合适。

    评估不是要么不做，要么全做。我们既可以评估全部架构，也可以评估部分架构，还可以只评估某个模型、概念、想法。最常用的评估方法是针对不同的场景审视某一块架构，还可以通过做实验，或者通过检查决策风险来开展评估。

    评估在难架构设计时非常有用，但它的作用还不止于此。评估可以用来检查任何工作成果，判断它们是否满足我们的需求。

    思维模式需要与一种循环流程配合使用，以便我们能够从一种思维模式快速切换到另一种。

2. 思考、动手、检查

    只要开发软件系统，每天都能接触到新东西。我们了解到的每一个新事件，都可能推动软件架构发生演变，以适应新情况。为了调整我们的思维模式跟上不断变化的环境，我们需要一套循环流程。

    这个方法分三步：思考、动手、检查。称为TDC循环。每一次循环迭代都针对一种特定的思维模式展开。

（1）迭代学习

    一次循环（迭代）可长可短，短则几分钟，长则几天。我更喜欢短周期的迭代，但有时也需要较长时间深入研究。每次迭代都遵循相同的步骤，但具体执行会因采用思维模式的不同而变化。

    思考：我们想了解什么？我们需要回答哪些问题？最大的风险是什么？想想如何制订计划获取信息，从而解答疑问、降低风险。

    动手：制作有形的、具体的东西，方便快捷地分享思路、检验想法。

    检查：慎重检查执行（上一步）的成果，以便决定下一步行动。从检查中获得的洞察和理解将告诉我们下一步做什么。然后再回到第一步----思考。

（2）组合运用思维模式

    你可以把四种思维模式想象成四个工具箱，每个箱子里都装着适合特定类型设计工作的工具。挑选合适的思维模式，才能在深入理解总是的同时降低风险。

    理解用于获取利益相关方的诉求，并将这些诉求转化为清晰的产品需求。探索则着眼于寻找各种解决问题的模式、技术、方案。展示对系统进行建模，以便我们有具体的对象进行推演和分享。评估则对模型和需求进行验证。

      

    在工作中，我们需要快速地切换思维模式，比如在一次对话中就可能多次改变思维模式。在后面的设计研讨会部分，我们将设置情境，要求参与者切换思维模式，以便得到理想的结果。