感觉软件设计和其他领域不同。软件设计是要求你尽量做什么，而其他领域是要求你尽量不做什么。
怎么说呢，比如写一个系统，业务方要求你去少写 bug；出去玩，朋友告诉你不要迟到。
但是对于系统设计来说，告诉你不做什么是没有用的，只有告诉你怎么做才能做好。
一些笔记
代码坏味道：
- 僵化性。软件代码之间耦合严重，难以改动，任何微小的改动都会引起更大范围的改动。
- 脆弱性。脆弱则是微小的改动容易引起莫名其妙的崩溃或者 bug，出现 bug 的地方看似与改动的地方毫无关联，或者软件进行了一个看似简单的改动，重新启动，然后就莫名其妙地崩溃了。
- 牢固性。想要复用软件的一部分功能，却无法容易地将这部分功能从其他部分中分离出来。需要低耦合服务。
- 晦涩性。如果代码晦涩难懂，必然会导致代码的维护者以设计者不期望的方式对代码进行修改，导致系统腐坏变质。
例子：
- 僵化性代码的例子是滥用了继承，导致添加一个小功能，所有的基类和派生类都要修改。
- 脆弱性代码的例子是引入全局依赖，导致意外的修改扩散。每当我看到很多全局变量的时候，对程序的掌控感荡然无存。
- 牢固性代码的例子是超大类，由于类内部是可以任意访问，所有的巨量函数和属性组成了一个巨大完全图，牵一发而动全身，根本不知道从哪里下手。
- 晦涩性代码的例子是过多 if 语句，一开始可能还好，最后 if 越加越多，导致看完都成问题。
4+1 视图模型认为，一个完整的软件设计模型，应该包括 5 部分的内容：
- 逻辑视图：描述软件的功能逻辑，由哪些模块组成，模块中包含哪些类，其依赖关系如何。
- 开发视图：包括系统架构层面的层次划分，包的管理，依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性，不同视角看到的可能是同一个东西，开发视图中一个程序包，可能正好对应逻辑视图中的一个功能模块。
- 过程视图：描述程序运行期的进程、线程、对象实例，以及与此相关的并发、同步、通信等问题。
- 物理视图：描述软件如何安装并部署到物理的服务上，以及不同的服务器之间如何关联、通信。
- 场景视图：针对具体的用例场景，将上述 4 个视图关联起来，一方面从业务角度描述，功能流程如何完成，一方面从软件角度描述，相关组成部分如何互相依赖、调用。
一个合格的架构师必须是一个合格的产品经理、一个合格的研发、一个合格的测试，架构师的职责就是基于公司的战略和资源定位产品的核心价值、基于业务做技术选型、规范和指导研发、构建各维度的测试。
如果我刚刚称为公司的架构师，我会和决策层统一公司的核心价值，并以 PPT 的形式体现承载价值的核心功能。达成一致后，召集全体研发、测试(如有)开会统一思想，包括产品功能、性能指标、版本管理、部署上线、交付时间等，都必须是可量化的。期间，可以发动群众集思广益，收集有建设性建议并和决策层讨论并最终定版，以产品功能说明书作为交付物。之后，基于终版功能及指标，做技术架构选择，以架构部署图作为交付物，并召集资深开会讨论，查缺补漏。之后，召集全体开发、测试(如有)开会，以使每个人都清楚自己的交付物和指标。之后，就可以开始功能迭代过程了。
综上，核心价值确定第一位，统一思想第二位，技术选型第三位，其他都可以见招拆招，或直接水到渠成了。