详细设计的阶段（预先设计）

详细设计的阶段（预先设计）所以，为了更好的观察和设计，我写下了这篇文章来总结它们，还有诸多细节待我去整理。演进式架构。依赖于持续的投入，来改进系统的架构。它将在下一篇文章中讨论的内容（PS：不知道什么时候能写完）。瀑布模型最早强调系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为 ‘系统发展生命周期’。[wiki_waterfall]当然了，现代的瀑布式开发，也开发发生了一些变化。敏捷软件开发，强调迭代与开发速度，并也非没有设计。于是乎，在不断碰撞的结果之下，产生了新的软件开发模式：小步的预先设计 持续性的架构设计——演进式架构。小步预先设计。即在不同的几个阶段里，实施不同的架构、组件、接口设计方案。

敏捷并不是没有设计，而是打散设计过程，让设计更贴合需求。

如我们所见，在过去的几年~十几~几十~近百年里，因为互联网的蓬勃发展导致软件工程，发生了一些显著的变化。首先，软件的发布周期由几个月一次，变成了一天几次。与此同时，软件的开发模式由瀑布式开发转向了敏捷开发模式，包含 “中华田园式敏捷” 软件开发（笑~）。

越来越短的 deadline，越来越快的发布速度，使得软件质量正在变差。尽管大部分的软件无法存活下来，在架构还没有腐烂的时候，公司已经倒闭了。然而，缺少架构设计的软件，将会导致一次又一次的软件重写。每隔个一年半载，开发人员就狠不得重写整个应用，然后就重写了。出现这种原因，有多种多样的，如：技术债务过多，导致代码腐烂。虽然，在某些公司里重写有助于 KPI，但是并非所有的公司都是如此。

扯远了，让我们回到主题上，看看敏捷

设计的变更（TBC）

瀑布模型最早强调系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为 ‘系统发展生命周期’。[wiki_waterfall]

当然了，现代的瀑布式开发，也开发发生了一些变化。敏捷软件开发，强调迭代与开发速度，并也非没有设计。于是乎，在不断碰撞的结果之下，产生了新的软件开发模式：小步的预先设计 持续性的架构设计——演进式架构。

• 小步预先设计。即在不同的几个阶段里，实施不同的架构、组件、接口设计方案。

• 演进式架构。依赖于持续的投入，来改进系统的架构。它将在下一篇文章中讨论的内容（PS：不知道什么时候能写完）。

所以，为了更好的观察和设计，我写下了这篇文章来总结它们，还有诸多细节待我去整理。

前期的预先设计：类瀑布模型

与瀑布模型不同的是，敏捷的设计强调的是轻量型的设计。相关的设计，可能在几天内，或者是一两个星期内设计及实施——依赖于资深的开发人员。而这样的类瀑布模型的设计，主要由两个阶段来体现：Inception Interation 0。

设计阶段：Inception

Inception 是 ThoughtWorks 多年以来使用的启动软件设计和交付项目的方法，通过 3 天到两周的时间，采用集中式、互动式的设计工作坊，帮助客户在最短时间内达成对项目范围的一致，快速进入项目交付。[^what_inception]

在这 3 天 ~ 两周的时间里，我们会进行最重要的系统架构设计，而设计的方案也是轻量级的。它只会包含整个系统的架构，以及少数的落地代码。

概念验证。概念验证（PoC，即 Proof of concept）是对某些想法的一个较短而不完整的实现，以证明其可行性，示范其原理，其目的是为了验证一些概念或理论[^wiki_poc]。

对于大部分项目来说，它们并不需要一个概念验证的过程。概念验证，只针对于我们打算在系统中采用新的架构，而这个新的架构在组织内部没有采用过，或者说采用得特别少，因此需要验证这种新的架构模式新的概念能落地。诸如于计划在项目中采用微前端，那么我们就需要去实践它，并证明它在项目中是可行的。

产出物：概念的可靠性及验证代码

系统架构设计。常规的系统架构设计，它包含了系统的技术选型，及对应的应用架构、业务架构、部署架构等。值得注意的是，这里的设计并非详细设计，只是大致的逻辑关系。

产出物：概念和架构图。

系统架构验证。又也可以称为原型系统（Hello World 们），它与 PoC 不同的是：它不仅仅包含 PoC 阶段的应用代码，还包含了一些架构可行性相关的代码实施。

产出物：系统可运行。

实施阶段：Interation 0

在这个阶段，主要是集成基础设施，完善整个系统的应用体系。

创建、更新脚手架（boilerplate）。对，就是拿出相应的框架、架构、应用的 hello world，更新对应的依赖，以满足项目的要求。对于不存在脚手架的项目来说，则是创建一个新的脚手架。它不仅仅是框架的脚手架，还包含了平台、公司特定的代码，以及各种代码规范，如 Git Hooks——pre-commit pre-push，前端的 TSLint 等。

产出物 1：可复用的项目模板。

对于前后端分离应用来说，它们需要一个 API 管理工具，用于制作契约。与此同时，对于前端开发来说，还需要一个 Mock Server。

产出物：API 管理平台及 Mock Server。

最小可行系统。它包含了之前的架构相关的代码，还包含了 DevOps 相关的代码（诸如于流水线等），让整个系统能完整运行出来。与此同时，系统的每个子系统，如前端、后端、移动端等，都能以 hello world 的形式工作起来。对于移动应用来说，它是可发布的状态——所以它意味着需要申请一系列相关的账号等。

产出物：系统随时可部署

模范代码。和之前强调的一样，要提供一个可供其它团队成员参考的代码。如果有时间编写代码，以通过代码生成的方式来生成模板代码，那是再好不过了。

产出物：可参考的功能代码。

搭建设计系统。对于组件化架构来说，设计系统是一个非常重要的基础设施。它可能只包含了 Style Guide，基础的组件库等。不过，这些并不重要，哪怕没有这样的系统，只要保证不出现大量地重复代码也可以。其相关的实践有 Storybook 等。

产出物：可视化的组件中心。

迭代中的预先设计

与此同时，在每个迭代进行的过程中，我们仍然会包含一系列的设计。

迭代中

API 接口/契约设计。无需废话。

产出物：API 接口其及 Mock Server。

建模。无需废话。不过，对于采用 DDD 的项目来说，它可能会稍微麻烦一些。

产出物：数据库模型、领域模型。

组件设计。项目开发的过程中，并非所有的组件都能满足我们的需求。为了不阻塞项目的开发，往往需要把一些相关组件的开发前置。它可能是在项目刚启动的时候，还可能是在迭代开始的时候进行。

产出物：前端组件

其它

暂时没有想到其它的了。

相关内容：『新项目检查清单』，从另外一个维度来考虑基础设施。

[what_inception]: https://www.tuzei8.com/what-is-an-inception/[wiki_waterfall]: https://zh.wikipedia.org/wiki/瀑布模型[wiki_poc]: https://zh.wikipedia.org/zh-hans/概念验证