敏捷软件中的预先设计

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

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

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

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

设计的变更(TBC)

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

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

  • 小步预先设计。即在不同的几个阶段里,实施不同的架构、组件、接口设计方案。
  • 演进式架构。依赖于持续的投入,来改进系统的架构。它将在下一篇文章中讨论的内容(PS:不知道什么时候能写完)。

所以,为了更好的观察和设计,我写下了这篇文章来总结它们。

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

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

设计阶段:Inception

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

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

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

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

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

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

产出物:概念和架构图。

系统架构验证。又也可以称为 原型系统 (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 的项目来说,它可能会稍微麻烦一些。

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

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

产出物:前端组件

其它

暂时没有想到其它的了。

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

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章