Day 04 - 行前说明 — 谈谈元件化开发与开发流程

https://ithelp.ithome.com.tw/upload/images/20210919/20120754cJdeMh9EhM.png
如昨天预告的一样,今天来介绍元件化开发的技术背景,它是什麽、为什麽重要,最後再讲一下元件的开发流程。

首先,「元件化开发」是由於前後端分离跟前端框架的兴起而达成的。

这边的前端框架主要是指 单页式应用( Single Page Application ) 的框架,帮前端把 HTML, CSS 和 JS 整合在一起,同步处理许多其他的问题方便开发,想知道更多的话可以看我之前在 Medium 写的文章:前端框架第 0 课:学习框架前该知道的事(偷业配)。

为什麽前後端能分离?

以往前後端分离之前,每个页面都是由後端即时吐 HTML 给浏览器的,但随着网页技术的发展、高互动性网站的大量需求,前端框架随之出现,在框架这边实作了单一 HTML 就可以渲染所有画面的机制,後端往後只要吐一份有引用框架程序码的 HTML 给浏览器就好,让前後端正式分离。

而前端透过框架来处理画面,後端只需要开出 API 来让前端去接资料就好。

前後端分离跟元件化开发有什麽关系?

前後端分离後,让前端可以很单纯地按造自己想要的方式去实作画面。

前端框架其实就只是在帮我们去整合前端独自开发时,都会所需要的一系列工具而诞生的。

而「元件」则是前端框架中的一项重要概念。

什麽是元件化开发?

在这里提一下「元件」的定义:「可复用、各自独立的 UI,如 Button」

在元件化开发时,我们所追求的是一个能开箱即用 ( out-of-the-box ) 的 UI 元件,因此 UI 元件本身除了画面之外,功能也需要健全(使用者事件处理、动画 和 一些基本情境)。

把网站中会需要的元素都切成一个个的 UI 元件後,接下来不论是继续开发还是团队合作上,都是在组装这些 UI 元件 并接上後端资料跟处理商业逻辑。

UI 元件组装的状况是指一个 UI 元件可以与其他 UI 元件组在一起,形成一个有更复杂或更适合专案情境的大 UI 元件。

例如:多选选项 (Checkbox) 可以跟输入框 (Input) 整合成一个 被点选後会跑出输入框的复合元件 ( CheckboxInput )。

(这部分一样会在 Day 06 的 Atomic Design 介绍更详细!)

一个 UI 元件会包含它的样式和功能等等所有东西,使用的人可以再按照这个元件开出来的属性对其进行客制化,而完全不用去理会内部实作逻辑,提升了开发速度的同时也减少了对整份程序码的认知负担。

更具体一点说,元件化开发就是在「拆分功能,封装元件,独立维护」。

元件化开发为什麽很重要?

「大事化小,小事化无。」(X

「把大页面拆成小区块,小区块再拆成一个个的元件。」(O

它为什麽很重要其实就跟上面提到元件化开发的本质一样:

  1. 拆分功能:不用一下子就把整个复杂页面写出来
  2. 封装元件:可复用、可组装成更复杂的元件或画面
  3. 独立维护:方便单元测试,从元件开始确保 Code 的稳定度

元件的开发流程

SOP 基本上是这样:先定义规格 (Spec),再实作介面(interface),最後实作元件 (Component),以下会照顺序来介绍这三个阶段在做什麽。

规格

规格基本上就是指你的元件要开发到什麽样的程度、会有哪些可能的使用情境,想要因应怎样的需求。

如果规格没在事先定义好的话,会让实作的工程师不知道这个元件应该要有哪些功能,元件有部分是大家公认会有的功能,但也有很多是根据使用情境才会产生的功能,像是 Tabs 的右边要不要有其他的功能键等等。

总之就是:定义好规格,才不会使後续在使用时才衍生太多额外需求,进而需要反覆回来修改。

虽然不可能一次到位,但确实可以减轻许多来来回回的流程。

更重要的是可以预防以下两个问题:

一、元件的自由度或是弹性不一

这点简单来说就是我们能对元件客制化到什麽程度,这也会直接影响到使用时的麻烦程度。

像是复合式的元件,我们是需要连能使用的元件都先定义好,还是就开一个介面给使用者使用,前者就是使用起来很方便,只要指定一些元素传进去就好,而後者则是需要每次都重写很多次子元素。

二、元件本身的复杂度不一

因应元件的弹性不一致,弹性越高的,元件的实作复杂度就越低,有些实作的成本会是在使用时体现,但若弹性很低,也就意味着我们事先对元件做了更多的处理,那麽使用时就能很方便少写很多程序码,也因此弹性就跟复杂度成反本,弹性越高的元件可以越不复杂,越低的处理越多事就会变越复杂,进而可能会影响到效能或使用上的不直觉。

介面

这边先引用一下维基百科对介面的定义:「程序编写或设计的方法论中作为程序元件功能的抽象化」。

这句话看起来很拗口,但其实就是你希望元件提供你的功能、也可以说是元件的 API,以 Button 来说,你会希望它可以点击 (onClick)、非同步操作时可以提供载入的状态 (Loading)、有按钮名称 (Label) 等等。

而介面对使用者来说就是一个黑盒子,使用者只要知道这个元件的介面是什麽,就能知道这个元件能做到哪些事情了。

先定义好介面,後续实作就只是再一一实现使用介面所预期的结果,如:disabled 要改变 CSS 跟 无效化元件。

同时,也会有许多 Component 都有类似的功能,这时候其实就能把共通的功能抽出来做成一个介面,後续的 Component 就都可以在这个介面的基础下再进行更多的封装,最常见的就是表单元件,至少会有当前的值 (value) 跟改变值的行为 (onChange),再来是识别用的 id、name,或是输入错误的提示 (error message) 等等。

介面的部分会在 Day 12 开始的 UML 篇章跟大家介绍得更仔细。

规格跟介面都介绍完後,我们可以看到只有最後的元件实作环节会跟你使用的框架 (React、Vue、Angular) 语法有关,所以虽然本系列实作的环节会用 React 来写,但基本上影响的程度不会到很大,至少需求跟架构都能在进入到实作前厘清。

元件实作

主要就是把定义好的介面一一实作出来,在 HTML 定义元件呈现的架构、CSS 去写样式,并需要处理各种情境的变化(像是 disabled 颜色要变淡)、而 JS 和 框架的语法来撰写互动逻辑和资料流的管理。

其实就是比较纯粹地在写 Code 啦,但如果前面的规格和需求步骤没有确实,在实作时就会要一直来来回回确认很多东西,其实对於整个开发体验(Developer Exprience)来说是很糟糕的。

如果你听完还很模糊的话没关系,在这先有个概念,等到 Day 21 实战演练系列开始时搭配程序码再回来看就会更有感罗!

上述讲完规格、需求和实作在做什麽之後,更细一点来讲流程会是这样:

  1. 由设 计师 和 PM 根据专案可能会应用到的功能与情境来定义出规格
  2. 工程师审视这些规格,看有没有更好更有效率的作法,主要是避免为了某些不重要的功能花了太多时间开发,後续使用跟维护上也会衍生很多成本
  3. 规格确认好後才开始思考跟定义元件的介面
  4. 介面定义好後,才会真的开始进入实作

如果想知道更多软件开发流程的细节,可以参考

软件业到底在干嘛?软件业开发流程、各职能大揭密!Software Development Process: How to Pick The Process That’s Right For You ,但实际上还是很看公司本身的体质,来决定采取怎样的开发流程哩!

小结

今天一样是打底的过程,让我们理解当今前端是如何能做到元件化开发的一些背景,像是前後端分离、应映前端框架而生的元件概念,以及对於元件化开发这一概念的解释。

整个元件化开发的概念基本上其实就是很常用到的东西要整合起来,遵循 DRY ( Don't Repeat Yourself ) 的原则,而对於前端来说,很常用到的就是各种 UI 元件了。

後半开发流程的部分则是给个概念,之後介绍完介面跟一些实作後再回来看效果会更好。

明天会介绍的是 UI 元件的分类系统,并会透过现行几个比较完整的 UI 元件库来介绍,敬请期待罗!


<<:  第19天 - 来试着做一个简易购物系统(3)建购物车的资料表、一点点SESSION

>>:  不要带着做法去要答案

人脸辨识-day20 资料预处理--1

在做模型训练时,要先将训练资料做一些事前的处理,为以下这几类:资料平衡、异常点处理、缺失值处理、特徵...

认识 C# 的 存取层级修饰词

修饰词~可以限制类别的存取层级 我的举例是:像是一些私密的东西你不想让别人随便乱看一样 就要设隐私权...

【4】实验 Batch size大小对训练模型的影响

Colab连结 相信每个人在学习ML时,都会遇到超参数 Batch size 应该要设置多少才好的问...

[FGL] 再探资料库 - 使用 fgldbsch 工具

Genero FGL为一个出自於资料库的语言,但怎麽和资料库搭上边的,我们还是需要来做一下理解。 ...

Day2 帐号申请与管理

访问控制(RAM)是什麽? 访问控制(Resource Access Management,RAM)...