分析和设计是我们经常听到和谈论的两个词，那么分析和设计的本质是什么？我们应该分析什么？我们应该如何设计？有些积累，突然问这些，会显得一时不知所措。接下来回答第一部分分析设计的本质。只有理解了本质，你才会懂得分析和设计。因此，在第二部分和第三部分，我们会详细讲软件的分析和设计方法，最后一部分会讲一些个人的经历。思考。一、分析与设计的本质1、分析的本质“分析”由“分”和“分析”组成，“分”是分开的意思，比较容易理解；“析”，左“木”和“劲”，“劲”连“金”，即劈木。推而广之，分析的本质就是洞察事物的内部要素，包括组成结构和运行机制。平时开发同学经常看到“需求分析”“软件分析”“架构分析”这些词。以“需求分析”为例，分析阶段要了解的内容有：需求背景、需求目的、需求目标、利益相关方、业务流程、业务依赖方、业务指标。分析的目的是找出隐藏在现象背后的本质，检验是否打破了对事物的认识，深入事物的内部看问题，就像我们高中学化学一样，分子结构决定现象的表现。在实际的软件开发中，产品同学提出的需求有时会包含技术方案。开发同学只有经过深入的分析，才可能提出更合理的技术方案，否则就是一个事实。在这种情况下，现有的解决方案存在问题。有一个人去美容的笑话。一个刚来的医生，不懂人体结构，一刀砍断了一条大动脉。结果，该人失血过多而死亡。“你真美”这个词就是这么来的。.笑话归笑话，这也说明如果分析不够充分，即对事物认识不足，事情往往会出问题。2、设计的本质“设计”和“吉”二字旁边有“衍”字，右边有“多”的意思，如“十”、“有”，即是，许多人的话的集合。推而广之，设计的本质就是在最佳方案中选择最佳方案，包括对方案的设计进行思考、选择和权衡。只有了解了当时的设计思路，才能快速掌握如何实现。在软件编码实现层面，我们有时会看到一些难以理解的逻辑。这些逻辑都是当时设计的产物。出现问题。好的设计凝聚着设计者的心思和心血，如经典的文学作品，蕴含着精湛的写作技巧；比如经典的影视桥段，里面有精彩的故事情节；意义。相反，不好的设计，起码会让人迷惑，不明白为什么要这样设计，影响美观和使用，大则造成事故。在《复杂系统的产品设计与开发》一书中，作者举了一个船的例子。面对如此复杂的系统，设计考虑不周全，结果设计的船下水就沉没了。在拉曼的一本书《UML和模式应用》中，分析和设计总结如下：分析是做正确的事；在经历了一些系统设计之后，再看，发现这两句话高度概括了分析设计的本质内涵。二、分析什么1、分析全景分析的出发点是问题本身，如现象、痛点、挑战、价值等，从这些基本点出发分析。比如在分析一个企业的时候，我喜欢从企业愿景和企业目标的角度去分析。看这个业务的干系人，也就是有哪些角色在使用这个业务，从这些干系人的角度去思考他们的本质诉求。正是他们的诉求构成了我们想做的事情的输入，无论外界如何。变化，他们的本质诉求不变。比如对于消费者来说，他们的诉求是用最短的时间、最少的钱、更好的体验去买到自己喜欢的产品；对于商家来说，他们的诉求是如何卖出更多的商品，如何获得更大的利润。反之，如果不关注利益关切的本质诉求，只是凭空想出来，认为有价值，那么一落地就会出现问题。明确了要做什么（What）之后，下一步就是思考业务流程和业务中包含的元素（businessobjects）、业务模型和业务能力（How）。这部分其实就是提供一个解决方案来实现前面提到的需求。分析的阶段必须非常详细。在软件分析中，有一些分析工具可以帮助我们更好地理解事物本身，下一节会具体讲到。分析的产物是业务模型和业务能力图。通过商业模式，可以看到商业是什么，有什么。通过业务能力图可以看到具体有哪些业务能力，可以支持哪些业务场景。往上一层分析就是分析商业价值链和商业模式。虽然这不是开发同学负责的领域，但还是了解一些比较好，这样才能对业务有更深入的了解。商业模式决定商业结构，业务结构决定交易结构，交易结构决定业务组成结构。利益相关者也来自业务结构。这部分是顶层分析，分析业务的可行性，也就是我们常说的Why。2、具体的分析方法在实践中，我们会看到多种多样的分析方法。这些方法本身并不重要，重要的是它能给我们带来什么帮助，我们为什么需要它，而我个人的观点是分析方法不要贪太多，真正融入到实践中去。一两种方法就够了。不要迷失在各种分析方法中。您确实需要了解分析的本质是什么。第一部分已经提到，分析的本质是洞察事物的构成，包括构成结构和运行机制。然后你看各种分析方法，都是为了搞清楚事物的组成结构和运行机制。比如黄金圈分析法，它包括三个层次（Why、What、How），从宏观到微观，从目的到实现，不断分析事物；另一个例子是5W2H，它真的很仔细地分析了一件事情。你在什么时间、地点以及为什么做了什么。回到软件分析本身，我们以前在大学里学的是软件工程、UML等课程。由于当时我们在研发和设计方面没有太多的实际经验，所以我们在学习的时候觉得这些内容比较空洞。不管怎样，老师要求我们这样做。这样做，就缺乏对这些UML图的理解。用例图：用户与系统最直接的交互。表达用户需要什么能力来满足他们的需求，关键是用户、目的和价值。活动图：在某类场景下，用户想要表达业务流程是什么样的。关键是业务活动和流程交互（只是业务层面，不是系统流程）。模型图：屏蔽业务细节，抽象出关键的业务元素及其联系，关键是从业务中抽象出来的实体要有实体之间的关联。现在再想想我们当时学习的UML课程。里面的各种图是为了帮助我们更好的理解和理解项目需求。画这些图不只是为了展示，而是要真正挖掘出业务能力是什么，系统能力是什么，业务模型是什么，有哪些对象，对象之间的关系是什么。在实际工作中，有些人在分析阶段并没有很好地实现这方面。其实问几个问题就很容易把它暴露出来，比如设计的类图的起点是什么，为什么这个类有这些职责，这个职责为什么在这个类而不是在另一个类。如果在分析阶段不做扎实，那么在设计阶段的投入就会比较少，或者说投入很浅，设计的质量就不会高，因为没有真正洞察到设计阶段。问题。3.一个分析案例使用2.1节中提到的分析方法。我当时也用上面的方法分析过一个分销业务。从下图可以看出业务发展思路是怎样的，用几个关键词来概括：打基础、拓渠道、强能力、建体系、数字化。有了这些理解，就更容易推断出在技术方面该做什么。以拓展渠道为例，当多个渠道打通时，会暴露出一些问题，比如答题成本比较高，所以有一个最重要的方面就是渠道准入的保障。如何降低渠道接入成本和答题成本，是技术端需要考虑的问题。三、到底如何设计1、设计全景如果说分析阶段是把东西打散，那么设计就是把打散的东西更好地组合起来。设计的核心是从分析中提取问题，即定义技术问题。这是非常困难的。比如你觉得某个设计不好，但是又说不出为什么不好，说明你对问题的认识不够高。.常见的技术问题包括：性能、可扩展性、稳定性、安全性、效率、体验、成本、数据一致性等。定义好技术问题后，下一步就是考察业界针对这个问题有哪些解决方案，有哪些优势以及各个方案的优缺点，比如数据的一致性，有事务性的方案，也有补偿方案，结合业务本身。做出选择，这个选择包括决策，而决策意味着权衡和平衡。不是随意的决定，而是有经验、原则、数据等决策依据支持的。设计包含原则，每个人都应该遵循这些原则。比如分层原则，这在软件设计中很常见。原理是大家开发过程中经验的结晶。以分层原理为例，大家可以深入思考。为什么分层，分层解决什么问题，需要分层多少层，怎么分层，只有深入思考这些原则后，在新场景设计时，才会得心应手，而不是死板地套用分层原则。2.设计原则设计原则，每个设计师都有自己的理解，很难有一个统一的设计原则，只能部分达成一致，比如分层原则，这个大家比较容易实现，设计原则应该是一系列的原则形成一个集合，而不是单一的。设计原则是通过大量实践沉淀出来的。我想说的是，如果你能根据自己的经验说出一些你看到的原理，那说明你真的实践过，思考过。否则，这些设计原则只是一些文字，不能转化设计经验和设计能力。下面是一些常用的设计原则。系统原则抽象分层原则领域原则重用原则简洁原则成本效率原则正交原则扩展原则演化原则3.两个设计案例对于上面提到的9条设计原则，这里主要讨论的是系统原则和正交互原则，系统原则是思考从全局的角度探讨系统间的交互。这个很重要，相当于一个灯塔。当你了解了整个系统的未来，你就可以清楚地知道每一步的执行都是为了未来。什么。反之，如果没有这个系统性的原则，我们所做的一切都只是着眼于点状的东西，而不是系统性的。以2.3节的例子为例，分析要做的事情后，画出如下图所示的系统架构图。从系统架构图中可以看出系统之间是如何交互的，链接逻辑是怎样的（注意：没有表达反向链接）。我们研究了数学中的正交性。最简单的理解就是两条直线垂直。在软件中，我们看到一些逻辑包含了很多逻辑。我们每次修改它，改变这个逻辑的结果都会影响到其他A逻辑，说明我们的逻辑耦合度比较高。正交性原则是将不同的变化点分开，使变化自治，即每次变化只影响自己，不会影响其他变化点。通常，我们在写代码的时候，有两种场景是相互影响的：代码重复和关系依赖。可以提取重复代码，为依赖部分抽象出一层防腐层。举个正交的例子，如果有一个需求：找一个叫John的员工，这段代码可以很快写完，但是仔细想想它的变化，至少可以想到以下三个变化：搜索会发生变化，不一定按姓名，例如按员工ID；搜索的对象会发生变化，不一定是员工，但也可能搜索学生；搜索规则会发生变化，不一定是按值搜索，也有可能是范围查找，比如找年龄在20到30之间的员工。当考虑到这些变化时，重新设计的效果会有所不同。面对业务场景的变化时，可以做到最小的改动，这就是设计能够降本增效的原因。四、关于分析设计的思考1、衡量标准衡量分析设计的标准是比较困难的。一般是从一些大的原则来看，比如复杂度、开放度等，但是很难有一个量化的指标来衡量复杂度有多高，开放度有多高。真正衡量好坏的好坏只能通过比较来判断好坏，比如多个解决方案之间的比较，哪个更容易衡量哪个更好。所以，我们要多看看别人是怎么设计的，有哪些好的设计思想值得借鉴，吸收更多好的设计思想和设计案例。设计中最糟糕的事情就是闭门造车。结果，设计出来的东西并不能很好地解决实际问题。我个人的经验是看业界的解决方案，看他们是怎么设计的，他们各自的特点，比如数据不一致的问题。有很多设计方案可以解决这个问题。有些方案对业务的侵入性比较大，需要做大量的修改，能没有入侵业务吗？阿里提出了TXC方案。这个设计非常好。用户只需要发表评论，业务改造不产生任何成本。这就是上面提到的简单设计原则。2.说到分析设计，很多人觉得很假。确实，在我开始工作的3年前，我也认为这是非常错误的。这不就是画画吗？后来才知道，真的不是一回事。给我印象最深的一件事是，我在滴滴的时候，我的主管给我们展示了我们未来在营销体系上要做的事情。他用一张系统架构图解释的很系统，知道我们以后想做什么。我们目前处于什么位置？在那段时间里，我们过着非常充实的生活，知道我们在做什么，我们将要做什么。经过一年半的时间，我们把当时系统架构图上的东西都完成了。回头看看，如果当时没有引导，我们还是天天做需求，来一个需求，做一个需求，就是说我们一开始做事情没有动力，看不到目标。设计内容确定后，最重要的就是实施。这个过程就是经验的积累。在实践过程中，会遇到一些问题，比如在发券的过程中如何扣除库存，如何保持交易的一致性，以及技术上的难点。我听过一个人说过一句话：要么看不到问题；还是回避问题，在实践中，我们会遇到各种各样的问题，但是我们忽略了，最后说这件事没有技术复杂性。我经常分享的一个观点是向上看第二层抽象，你的设计方案可能会改变。架构设计需要大量的实际经验。仅仅画一个架构图是不够的。需要在实践中反复检验，然后指导下一步更好的设计。我很欣赏的一句话是：把虚拟的东西变成真实的。3.将经验转化为能力我们有了一定的分析设计经验后，需要进一步将其转化为设计能力。设计能力是抽象的，需要在实践中检验。就像第三部分提到的设计，不如分析来说明具体的方法。设计本身就凝聚着心思和心血在其中。同时，设计是一门具有高度灵活性的艺术。因此，很难说出具体的设计方法，也不会有统一的方法。灵活性一定不能具体，所以这部分需要在大量实践的基础上提炼出设计原则，转化为设计能力。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
