聊聊工作台的可维护性

原文地址：https://yuque.antfin.com/nrdara/asd0u6/rp3na5

本文是在原来《再谈“面向未来中后台场景”》 文章上的进一步实践和探索。
在我们的看来，工作台的前端开发，核心目标就是降本提效。而这背后需要重塑的是生产方式，而生产方式 = 生产力（劳动力 + 生产资料）和生产关系的特定组合。
在工作台场景下，就是 前端 + 外包（劳动力）通过 IDE（或其他生产工具）对物料（或其他生产对象）的生产、组合或再改造。
抛去生产关系和生产工具不说，本文重点聊聊前端软件 “可维护性” 这件事。既然我们要聊如何提升工作台效能，那当然要从现有的成本构成开始说起。

维护成本占总研发成本的 67% 以上

看到这个，是不是有点不太敢相信，其实刚开始，笔者也有些不可思议。但越是深入了解，再结合自身的的体会，这个看似奇怪的结论似乎也有几份道理可讲。
从软件的一整个生命周期来看，我们 _参考一份评估模型 [1] _的不同软件时期工作量和时间的分布关系

我们可以看到前期包括设计、开发在内，仅占工作量的 40% 左右，而剩下的更新、升级工作量占比约占 60% 的工作量。

在 _另外一份论文__[2] _中，我们更能惊奇地看到，作者在近 30 多年的跨度中，软件的的维护成本更是趋于 90%。这也让我想起，在某些遗弃的角落，哪些各种维护不动的应用。

当然，根据不同的场景、统计方式，数据差异也会比较大，所以我们找到 一份报告_ [3]_ 用来说明不同论文的结论，如下所示：

AuthorMaintenance as a % of Build CostDaniel D. Galorath75%Stephen R. Schach67%Thomas M. Pigoski 80%Robert L. Glass40% – 80%Jussi Koskinen 90%

有些作者得出了最低 40% 的结论，有些作者得出了大于 90% 的结论，所以，通常来看，大家比较认可的一个数据是 67%，来自 Stephen R. Schach [4] 的结论：

结合这么多学者的研究，再看看手上各种老应用，是不是有那么一丝丝惊讶了呢？

可维护性是技术架构选型的重要依据

说到 维护成本，从更大的视角来看，其实是对 “软件质量（Software Quality）” 的控制。
软件质量的控制，按照 _CISQ (The Consortium for Information Software Quality??) 的模型 [6] [7] _可分为：

MAINTAINABILITYRELIABILITYSECURITYPERFORMANCE EFFICIENCY

首先按照 CISQ 的定义来看，在工作台场景下，综合考虑 软件成本 和 软件质量 之后，优先级应该是 MAINTAINABILITY RELIABILITY SECURITY PERFORMANCE EFFICIENCY 的。因为后三者更多的是一次性（或几次性）成本（但对质量来说至关重要），而 MAINTAINABILITY 更多的是和业务强相关的多次、频繁的成本，而且前面也说到了占比 67%。所以说，可维护性是综合软件质量和成本后最重要的考虑因素（其他几个相对次要）。

从另外一方面来看，我们在对软件做技术架构的目的是什么？通俗些说，就是又好又快地接业务需求，并长期支撑业务发展。在我看来，好与快之间，“好” 是 “长期” 的 “快” 的基础。而这个 “好” 其实本质上就对软件质量的控制， “快” 则是对软件成本和效率的控制。

如此来看来，可维护性就是我们技术架构选型的重要依据了。

PS：
对所有软件都适用吗？其实不然！对于大促场景下的临时导购页面，考虑到无需过多的人员协同，且页面的生命周期相对较短，快速上线、页面 PERFORMANCE 是更重要的因素，可维护性就显得不那么重要。

PPS
根据 _IEEE Std 14764-2006 _的定义，维护工作主要有两类：修正型的和增强型的。

提高可维护性的几点思路和想法

其实这块挺难写的，我尝试通过 SOLID 或其他软件设计原则来拆解，但都不太理想。所以，也只能通过不完全枚举来先简单聊聊了。

基础：标准 规范为什么标准很重要？We want to support our products and solutions for as long as we possibly can. We don’t want to have to constantly start from scratch and see our previous work become obsolete.
-- https://blog.bosch-si.com/bosch-iot-suite/why-standards-matter-in-the-iot/A standard is a repeatable, harmonised, agreed and documented way of doing something. Standards contain technical specifications or other precise criteria designed to be used consistently as a rule, guideline, or definition. They help to make life simpler and increase the reliability and the effectiveness of many of the goods and services we use.
-- https://www.irena.org/inspire/Standards/What-are-Standards

简单搜索了一些关于 “why standards matter” 的回答，可以看到标准对于我们软件的长时间的维护、复用、可靠性以及开发成本都有着重要影响。

举个反面例子，关于 _视频信号传输 [10] _的（当然也有历史原因和相关取舍）：

前端运行时规范应该是什么？

React 虽然已经是集团内部 “事实上的规范了”，但在工作台场景下，依旧有着许多的担忧。在拉长的时间维度上看，它会不会是另外一种的 “jQuery”？

在一篇 The Brutal Lifecycle of JavaScript Frameworks [11] 的文章中，作者通过在 Stack Overflow 上问题数量来分析了前端运行时框架的生命周期，也是挺值得我们深思的。

我们能看到，在 2013 年左右，jQuery 无意是最正确的选择，帮我们解决了很多现实的问题，比如最重要的便是兼容性问题。但由于标准的逐渐推行，兼容性得以改善，也便慢慢失去了市场。相应的，也慢慢成为了一种包袱。

而现在，必须承认的是 React 是当下最正确的选择，但我们将时间拉长到 5 ~ 10 年，会是这样吗？在我看来 React 解决了我们最大的问题是：组件化（当然也有人认为是 Data 到 UI 的映射、或者渲染性能等等）。抛开数据映射和性能不聊（在我看来，不是当下最痛的点），所谓的组件化方案，也仅仅是 WebComponents 兼容问题的 “过渡方案”。

探索中的工作台标准与规范

这里的规范包括：运行时框架、表单、搭建协议、工程构建、模块加载等等。我们在这块的实践上，可以说是在 “狂奔” 来形容，技术选型也是比较 “激进”，比如：

搭建协议标准化，虽然集团有 _《阿里经济体中后台搭建协议规范》__[9] _，但在长期以及实践过程中，依旧有着不少的困难，所以，全量的 WebComponent 方案 正在探索和考虑中。运行时标准化，抛弃 Render Engine 的思路，让浏览器作为我们唯一核心的渲染引擎。尽管我们的 Render Engine 已经抽象到 400 行代码 都不到了。模块加载标准化，随着 ESM 兼容性的日趋好转，ESM 已经成为我们模型加载的最佳实践。随之带来的天然特性，便是 Bundle-Less，Module-Federation 等等。表单和列表规范，目前得益于 Formily 和 Alist，主要以这两套规范进行落地，也在尝试如何标准化。

通过一个 工作台标准化页面的 Demo 示例，大概感受一下应用以上标准的页面，源代码如下：

 common-layout 
 krump-app-header slot="header" /krump-app-header 
 common-menu slot="menu" krump-app-id="1" /common-menu 
 main slot="main" 
 sl-card 
 div slot="header" 我是 Formily 测试表单 /div 
 schema-form
 onSubmit="data:text/javascript,await import('https://jspm.1688.com/@ali/ks-b5aed4ed-7d77-4391@daily').then(d = d.onSubmit)"
 formily.field
 name="name"
 x-component="Input"
 x-component-props='data:application/json,{"label": "name"}'
 /formily.field 
 formily.field
 name="address"
 x-component="Input"
 x-component-props='data:application/json,{"label": "address"}'
 /formily.field 
 formily.submit /formily.submit 
 /schema-form 
 /sl-card 
 /main 
 /common-layout 

标准 规范对于软件质量的提升

根据 _ISO/IEC 9126 的模型 __[8] _，我们可以简单看一下以上标准对软件质量的影响。
_

Analysability

UI 描述：HTML WebComponents 对 UI 的描述达到了非常干净的抽离（和 JSX、JSON 相比）逻辑描述：由于 ESM 的引入，Bundle-Less 的代码使人更容易阅读，甚至不用看源码（与之相对的缺点是代码安全性问题）

Changeability

通过 define 不同的 element 和 slot，对 UI 的描述和实现可以做充分的抽离（ JSON 也有此类效果）

Stability

和框架生命周期相比，规范的生命周期往往是它的数倍，也就意味着，我们的成本也将呈现数倍的下降（仅是猜测，无相关数据佐证）

Testability

按照组件维度的单测，和 React 相比，无明显的优势、或提升

Portability

Adaptability：WebComponents 可与任何框架进行适配集成Replaceability：定义与实现分离，以及特定的 enhance 能力使得组件的可替换性大大增强，而非 js 的强依赖Installability：页面写完即可运行，无需过多的依赖、打包、部署Co-existence：非排他，可共存。可在 vue、react 中使用，也可以将 vue、react 集成到 WebComponents

Reliability

Maturity：Custom Element V0 的提出到 V1 的大面积推广，光是规范的提出就经历2 ~ 3 年（2014 至?2017），截止目前 2021 已经历了 7 年之久，已经是很多框架的一生了（如 backbone）。Recoverability、Fault tolerance：WebComponents 做了相当多的容错和可修复机制，比如未实现的 element、替换等等。

Learnability

相对框架的学习，HTML + CSS + JavaScript 的学习曲线显得更为平滑，其知识的适用时间跨度也更为长久。设计原则：随用随弃的重要性

你的前端项目代码是不是越来越多，而且只能越来越多。虽然 Data、Service、Controller、View 分层分得好好的，但代码依旧越来越臃肿，越来越不敢删？生怕有些不常用的功能还在使用某个功能。

引用即使用

得益于 ESM 的特性，我们所有的 JS 模块都采用的 HTTP Import，这就意味着 “引用即使用”（反之 “非引用即弃用”）。当相关模块被替换的时候，引用也就随着消失，项目运行时代码量也就随着发生变动。

import Link from 'https://jspm.1688.com/@ali/ks-krump-test1@0.0.1';
// 升级更换其他组件之后 == 
import Link from 'https://jspm.1688.com/@ali/ks-krump-component-link@0.0.1';

替换原则

从 里氏代换原则(Liskov Substitution Principle LSP) 的角度出发来考虑。随着各种规范 Interface 的确定，我们能替换和随用随弃的能力将得到进一步的释放，项目可维护性将得到进一步的提升。比如：

 form 
 // 定义了 custom element 的 value、change 接口
 input name='date" is="vue-date-picker" / 
 /form 
// 组件实现
 script type="module" src="https://9i0i.com/pic.php?p=./vue-date-picker.js" /script 
// js升级为其他框架之后 == 
 form 
 input name='date" is="angular-date-picker" / 
 /form 
 script type="module" src="https://9i0i.com/pic.php?p=./angular-date-picker.js" /script 

人的协同：学习曲线和进场成本

工作台场景的外包化是基于成本考量的重要一环，人员的培训、学习，以及代码的质量控制是此场景下需要重点考虑的。

学习成本

更低的成本：用 HTML 的 UI 描述，降低了学习工作台搭建协议的成本。WebComponents 的强悍集成能力，理论上能让开发者随意地选择自己熟悉的 UI 库，比如 Ant Design、Fusion 等，也能让开发者随意地选择框架，比如：React、Vue 等（同时需要避免泛滥）。

更长久的知识储备：在框架快速迭代的时期中，我们本周上更多地是在学习框架的各种接口和使用，如果转而对规范的学习，依托规范的生命周期，我们的知识理论上能得到更持久的应用。

进场成本

随着 WebIDE 的逐渐成熟，我们现有的工作台开发已经全量线上化，ProCode 也全量 WebIDE 化，这其中所能带来的优势是显而易见的。开发同学不需要关心开发工具的依赖，开箱即用。当然，这对后续的维护也是极为有利。

“页面即开发” 思路也正在探索，所有线上页面，只需一键开启 Debug，就能直接在线切换至 WebIDE 资源。并在修改完成后，提交工单即可发布上线。“轻开发”、“轻发布” 这些对于进场成本的降低，或者对于整体软件的可维护性有着重要的影响。否则，你可能还在找仓库源码的阶段的徘徊。

小结

通过对软件成本的拆解，我们能看到可维护性工作其实占了软件整体生命周期的近 2/3。对比工作台的成本，其实也能得出相似的结论。所以，我们出于对工作台维护成本的思考，来挖掘影响软件质量背后的因素，从而也看到软件可维护性的重要性。

在提升可维护性的几点思路中，由于前端还不那么成熟，所以，在现有体系下，标准和规范显得尤为重要，也是当下提升工作台场景下可维护性的重要突破口。在从基础架构出发的同时，我们也看到在应用 “软件设计原则” 对可维护性的重要影响，最后，对场景下工种的特点分析，我们还需要对 “人的协同” 的方面来提升软件的整体可维护性。

参考Research on Software Maintenance Cost of Influence Factor Analysis and Estimation MethodWhich Factors Affect Software Projects Maintenance Cost More?Software Maintenance: Understanding and Estimating CostsSchach, R. (1999), _Software Engineering_, Fourth Edition, McGraw-Hill, Boston, MA, pp. 11.IEEE/ISO/IEC 14764-2006 - ISO/IEC/IEEE International Standard for Software Engineering - Software Life Cycle Processes - MaintenanceMEASURING CODE QUALITYhttps://en.wikipedia.org/wiki/Software_qualityhttps://en.wikipedia.org/wiki/ISO/IEC_9126《阿里经济体中后台搭建协议规范》https://en.wikipedia.org/wiki/List_of_video_connectorsThe Brutal Lifecycle of JavaScript Frameworks
本文转自网络，原文链接：https://developer.aliyun.com/article/783785
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！