低代码时代开发者并不会被取代，而是将从繁重的、重复的代码中解放出来，去参与更具价值的开发环节。
正如软件行业生态真正想要做的事情，其实是替代桌面电脑；平台和工具发展的方向其实是要替代传统的工作方式。对于低代码开发平台来说，与其说它会“干掉”开发者，不如说是替代了传统的开发模式。
根据 Frevvo 的研究，借助低代码开发可以帮助企业数字化转型的速度提高 69％，这是低代码开发最直观的一个影响，大大缩减了产品的开发周期和企业开发者的工作量，对技术创新型企业与开发者都是重大利好。
由此可见，低代码开发的主要优势是速度，即“追求少的代码量，完成最多的开发工作”。而能支撑这一优势的前提，是低代码开发工具本身就具备非常专业的“代码逻辑”。
这类代码逻辑体现为在某一垂直领域或技术水平上的技术壁垒和优势，非专业开发者正是借助了它们，才明显提高了产品或者自身工具的性能。所以，低代码的形式有很多种，不限于Outsystems、PowerApps、活字格等“开发平台”，还有在垂直领域发力的新一代控件产品，同样不容忽视。
下面，让我们以企业最常见的场景 —— 表格为例，与大家共同探讨，专业开发者是如何帮助非专业开发人员解放双手，用最少的代码量，打造出一个个更具创意的企业级应用程序的。
一、前言
大家应该都知道，很多企业的 IT 业务是从一张表格开始的。团队沟通中的信息共享大量依赖于表格，文档、报告、凭证以及基础数据的汇总分析，大部分都需要依靠表格的形式来进行决策的支持。
而随着远程办公的兴起，在线表格产品也成为很多企业必备的工具之一。但综合性的协同办公产品大部分将更多的精力投入在了文档工具的优化当中，对于表格场景并没有投入足够多的时间与精力；另一方面表格产品看似很简单，但背后其实涉及到很多的技术实现，以及产品团队对于表格场景的熟悉度处理，目前的泛用性在线表格工具平台均不具备相应的经验与能力。
那么，对于一款前端表格控件来说，有哪些需要进行优化的地方呢？我们下面分别从产品优化与体验优化两方面来进行分析。
二、表格控件的产品优化
B/S 作为 Web 兴起之后的一种网络结构模式，统一了客户端，将系统功能实现的核心部分集中到服务器上。
但随之而来的问题是多浏览器差异、浏览器沙箱机制、内存访问受限、客户端性能低下等。作为数据载体的表格，最直接的影响就是经常会被“吐槽”卡顿，UI 界面“假死”，界面操作不流畅等。
引起这些问题的症结在于浏览器渲染引擎的基础原理：当界面元素越多，浏览器的渲染时间会显著增长，内存消耗会越大。这对于强计算逻辑的前端表格控件来说，无疑是棘手的难题。
而开发一个前端表格在产品层面主要有三个技术难点需要进行优化：性能、内存消耗和可靠性。
1、性能优化
现代应用程序为了追求更好的用户体验，需要对 UI 界面反复优化，而频繁的修改界面 UI 元素，将引发多次浏览器重绘。在这个过程中，UI 元素的创建及修改，会激活内部垃圾回收机制，影响数据处理效率。
除此之外，前端开发环境的多样化、各类高 DPI 设备、手机、平板、4K 显示屏、企业大屏等，这些无不加重了企业应用系统的处理负担。
为此，业内目前最佳的解决方案是使用 Canvas 绘制模型。
Canvas 主要用于在网页上绘制图像，可以将其理解为画布，开发者们在这个画布上构建想要的效果。它与在浏览器中运行的其他应用有所不同，由于 Canvas 只在屏幕上特定的区域执行并显示效果，可以说它的功能是独占的，因此不太会受到页面上其他内容的影响，反之也是如此。
作为一种不依赖于浏览器解析的方式，使用 Canvas 绘制模型不仅可以解决性能问题，和 DOM 相比还提供了不失真的页面打印，做到所见即所得。
2、内存优化
随着前端工程化的高速发展，各种前端工程脚手架日渐成熟，WebComponent 标准被提上日程，企业开始由 C/S 向 B/S 应用转型。为了优化内存，这就要求前端开发者，需要面对单线程处理复杂业务数据的挑战。
对于表格控件这类松散的文档结构，业内目前的最佳实践是采用稀疏矩阵存储模型（Sparse Array)来保存数据。
稀疏矩阵在机器学习方面是很常见的。由于稀疏矩阵含有许多数值为零的元素，可以用来压缩矩阵对象的内存台面空间，或者加速多数机器学习程序。
而在表格场景中，相较于传统的链式存储或数组存储，稀疏矩阵存储构建了基于行索引的数据字典，在松散布局的表格数据中，稀疏矩阵只会对非空数据进行存储，而不需要对空数据开辟额外的内存空间。
这种特殊的存储策略，不仅节省了内存消耗，也使得数据片段化变得更加容易。借助这个特性，开发者甚至可以随时替换或恢复整个存储结构中的任何一个级别的节点，实现高效的数据回滚和数据恢复。
3、可靠性优化
传统前端表格应用计算的特点，是没有稳定的框架计算器、语言计算精度差、表格计算依赖复杂。
随着企业数字系统应用的越来越深入，业务计算方式也变的越来越复杂，灵活度要求也越来越高。为了解决这个问题，必须了解计算引擎的计算流程后进行相应的可靠性优化。
image.png
如图所示是计算引擎在构建计算依赖链时的一个简单的流程图。表达式树从计算存储模型中找到对应的根节点以及根节点标识，随后遍历整个表达式树，找出其他依赖标识，构建依赖关系。
当整个依赖链中的任意节点发生变化时，如果沿着这条依赖链，可以查找依赖节点并进行重算，那么在这个过程中，没有在依赖链中的节点是不会发生重算计算的，也就是我们所说的没有脏值运算。
进行这样的机制优化后，可以大大提升了表格产品的运算速度，从而带来更好的使用体验和更加精准的运算结果。
4、操作体验优化
随着业务场景的丰富，表格工具正在承载着更多的功能。例如触摸支持、富文本支持、前端 Excel 导入导出、JSON 存储等。
我们以触摸支持为例，随着大屏时代的来临，触摸操作成为了一项愈发普遍的使用场景。对于触摸来说，很多时候最难的并不是技术实现，而是对于场景的理解。用手机操作技术文档，单击单元格时，对应的位置是放大还是不放大？
对于不同的场景，用户需要的反馈是不同的，这些都是一款表格产品需要考虑到的优化方向。
在一切以用户体验为中心的互联网时代，任何开发活动都应该以改善用户体验为终极目标，产品优化当然也不例外，产品优化最忌陷入纯粹为了追求技术极限而优化的境地。
上述的四个产品优化方案，其实都是我和垂直领域的表格控件工具平台技术团队沟通后了解到的，他们在实际应用场景中解决的实际问题。
就像葡萄城 SpreadJS 纯前端表格控件 的研发团队，是业内最早进行表格产品研发的团队，只要是需要用到 Excel 文件上信息化系统的场景，他们的产品基本都已经覆盖到了。
而 SpreadJS 之所以敢于提出替代传统 Excel 的使用，一定是在产品层面进行了大量的优化、迭代。据我了解，在性能优化方面 SpreadJS 除了引入了 Canvas 绘制模型，还率先引入了双缓存画布技术，从而解决了常见的闪屏问题；此外还提供了支撑复杂逻辑运算的计算引擎，从而帮助开发者打造稳定可靠的应用系统。
想要在产品层面进行优化，一方面需要“吃透”表格产品的底层技术逻辑，另一方面需要有大量实际的场景应用经验，这是想要做独立开发的企业所不具备的，而借助像 SpreadJS 这类垂直领域的第三方工具，则可以达到事半功倍的效果。
三、结语
正如我们前面所说，开发一款前端表格类组件最难的不是技术，而是要对 Excel 的熟悉程度。纯技术的问题，在很多时候是难不住开发者的，无非是时间与精力的差异。而一个好的产品很重要的一点，就是对于产品使用场景的细节把控。
就像在表格类工具中有一个算投资回报率的公式，几乎没有人知道这个公式用 Excel、Google Doc 算出来的结果是不一样的。而这个小到会被所有人忽律的细节，正是 SpreadJS 的研发团队告诉我的。
随着社会的发展，市场需要一种更灵活、成本更低、效率更高的开发解决方案。作为企业级服务领域的一个全新赛道，低代码开发平台的市场逐渐变得更加清晰，而行业对于开发者的定义或许也会随之改变。
长远来看，低代码平台的发展对于开发者来说即是机遇也是挑战。我之所以不喜欢码农这个词，是因为敲代码只是开发者掌握的最最基本的能力，而开发者的价值绝不仅限于此。
“专业的人做专业的事”，低代码的出现并不会“干掉”开发者，反而给了开发者更多时间、更大的平台，去用更专业的技术开发新世界、探索新世界，这可能才是开发者的价值所在。
网友评论