孤尽班第一天笔记--架构设计

建筑师在工人开始造房子前需要先设计好房子的框架和外观，软件工程师在做一款产品时同样要先设计好产品的架构。好的框架应该像房子的栋梁一样，屹立多年而不必更换。

这节课主要讨论的软件架构设计的需求分析、设计原则和交付品。

需求分析：

架构设计从用户提出第一个需求就已经开始了。架构设计的第一步，也是最重要的一步，就是理解和挖掘用户的诉求，以及背后的逻辑，并转化成可行性的分析结果。起初，用户的诉求是零碎和松散的，这在用户诉求的头脑风暴中体现的最明显。我们的这阶段的工作就是要把这种非结构化的输入进行结构化，然后确定系统的职责，并将系统模块化。

在分析用户需求时，我们要注意确定需求的边界，并不是所有的需求都是平等的。有一种在敏捷开发中经常用到的方法，我们可以把需求分成MUST-HAVE, SHOULD-HAVE, NICE-TO-HAVE等几大类，这样方便在后期开发中做出取舍。

一个可行的用户需求应该可以用“讲故事”的方式表述出来，即用户故事。用户故事讲好了，我们就能够分析出用户路径。用户路径是一个用户在用户故事中经历的每个与系统交互的节点。比如用户登录-->修改密码-->收到确认短信。这就是一个简单的用户路径。

要是有人提出不合理需求怎么办？经常会有客户一拍脑门就决定要上一个需求，比如有人想根据某APP的用户的手机壳的颜色来动态更改APP界面的颜色。这是我以前在报上看到了，据说当事程序员和提这个需求的人打起来了。面对这种没有调研、没有目标、没有逻辑的无脑需求，孤尽老师在课上给出了应对方法：

1、用数据化结果否定需求合理性

2、用正反案例来说明需求需要改进的地方

3、用户路径和触点推演需求合理性

如果遇到老板或者是强势业务方提出这样的需求呢？

应对：

1、先肯定需求价值再提出需求实现的成本

2、给出更好的需求替代方案

3、从数据和案例角度说明需求快速上线危害性

只要是程序员，一定会遇到不合理需求。遇到时我们可能会生气，其实不必要。相反，我们可以把它看成是成长的机会。如果我们没法反驳这种不合理需求，要么是因为它真的合理，要么就是因为我们对它的分析不够到位，没法拿出有力的反驳论据。

设计原则

KISS原则

Keep it simple and smile

架构的理念是大道至简：解决问题

这里我想举个亲身经历的反例。组里曾经就有一个自封的架构师在一起讨论架构时，只要想到一个微服务就会在架构图上画个圈来表示这个微服务。渐渐地，他的架构图越来越大，非常像摊开的煎饼。他需要的肯定不是煎饼、而是一个KISS。

现代软件需要很强的协调能力，保持微笑，迎接各种否定

时刻保持微笑真的很难，说来容易，做起来可得需要深厚扎实的功底来保证自己做到东西经得起挑战。我一般就比较心虚，当有同事质疑我的工作时（没有恶意的那种），虽然我面带微笑，但内心还是万马奔腾。要想有底气，还得把功练。

DRY原则

Don't Repeat Yourself

一切重复的代码都可以抽象

重复代码的危害性：不一致性；代码冗余；容易出bug

DRY原则是我一直努力在坚持的原则。在写代码时，我会把可以重复使用的代码封装成函数。这样，代码变得更加简洁和易读。如果需要改动，我只要改动封装的函数里的代码，不必担心重复代码可能带来的不一致性的隐患。

未完待续，明天接着感悟。