Blog

Blog

PHODAL

敏捷软件中的预先设计

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

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

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

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

设计的变更(TBC)

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

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

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

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

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

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

设计阶段:Inception

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

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

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

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

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

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

产出物:概念和架构图。

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

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

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

产出物:前端组件

其它

暂时没有想到其它的了。

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


  1. https://zh.wikipedia.org/wiki/瀑布模型 

  2. https://www.tuzei8.com/what-is-an-inception/ 

  3. https://zh.wikipedia.org/zh-hans/概念验证 

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《前端架构:从入门到微前端》

《前端架构:从入门到微前端》是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前端工程师更好地进行系统设计。

前端架构包含以下五部分内容:

  • 设计:讲述了架构设计的模式,以及设计和制定前端工作流。
  • 基础:通过深入构建系统、单页面应用原理、前端知识体系等,来构建出完整的前端应用架构体系。
  • 实施:通过与代码结构的方式,介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
  • 微前端:引入6种微前端的概念,以及如何划分、设计微前端应用,并展示了如何实现这6种微前端架构。
  • 演进:提出更新、迁移、重构、重写、重新架构等架构演进方式,来帮助开发人员更好地设计演进式架构。
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签