低代码
更新时间：
概述
低代码近几年又火了一把，但“低代码”并不是一个新概念。有年纪大点的，应该对网页三剑客还有点印象，Dreamweaver 作为可视化开发的代表，当时可谓是名噪一时。
低代码的意义在于降低开发门槛，让不具备编码能力的从业者可以通过可视化、所见即所得来实现搭建 Web 应用的目的。
这个概念在当前又被拿来旧瓶装新酒，很大层面上是因为市场需求。目前所有行业都在谋求数字化管理、数字化转型，自然就会有人在找寻对应的工具来实现其转型目标。
无论是编程语言，还是低代码平台，本质上都是应用开发的工具。
低代码悖论
工具本身是为使用者所使用的，工具会具有学习成本、学习门槛，这是对使用者提出了要求。
工具本身能否满足搭建应用的需求，首先取决于工具本身的能力或局限性，其次取决于从业者对使用工具能力的掌握程度。
低代码平台对使用者的要求较低，但是其能实现的功能也是比较有限的。当应用的复杂度增长到一定程度，必然会超出低代码平台的能力范围。这也是为什么低代码平台搭建的应用大都生命周期比较短，往往只是初期的替代品。后期必然需要使用编程技术来重新实现。
如果不使用编程语言重新实现的话，那必然对低代码平台的本身的开发能力提出了很高了要求，最终低代码的开发会越来越接近于一门新的“开发语言”，无非是给软件世界里贡献了一门新的语言。
既然如此，何不选择一门成熟、生态活跃的开发语言来实现应用开发呢。
低代码平台该何去何从
虽然我抛出了问题，指出了低代码平台的局限性，但是低代码平台解决的痛点仍然是存在的。或许我们可以换个角度，只要能够延续低代码应用的生命周期，也就是说，让应用的复杂度增长到一定阶段的时候，可以直接通过开发语言来接棒应用的持续迭代。
事实上，这也不是一个新鲜的概念，而是业界一直存在的做法。比如 Shopify(目前最流行的电商应用搭建平台)，为了给用户提供灵活的定制能力，在可视化的基础上也推出了界面描述语言：Liquid。当然，Liquid 只是 UI 界面的解决方案，并不能全盘接手应用的整体演进，基于 Shopify 搭建的电商应用，其最终能达到的天花板依然局限在 Shopify 所提供的能力之下。
除了平台专属的描述性语言，还有一类平台，会开放允许用户使用通用的开发语言满足个性化的需求，记得笔者读大学的时候，早期的 QQ 空间就提供了这样的能力，允许用户使用 Javascript / HTML / CSS 来实现一些炫酷的功能，那个时候的中二少年们把 QQ 空间玩出了花。后面 QQ 空间陆续禁用了这个能力，大概是因为安全原因。
软件工程是一个综合的大工程，除了前端，还有数据库、运维、后端。
业界也有一些从某个角度入手的解决方案：
-
Design to Code：光速软件 是国内这个领域的领头羊。他们会根据设计稿，直接生成标准的前端代码：原生小程序代码或者 Vue 代码，其生成的代码可能比一个初级程序员写的还好。开发者可以基于其生成的代码，继续迭代开发。可惜的是，CodeFun 只能解决前端的开发问题。
-
PaaS(平台即服务)：服务商通过提供更好的 Web 应用开发的基础设施，来达到简化 Web 应用开发的目的。从云函数到云开发，很多厂商，特别是云服务厂商在这条道路上走得越来越远。
也有更加融合的平台，如：budibase，把可视化开发、PaaS服务进行了深度整合。、
殊途同归，大家都在围绕如何降低开发门槛在不断前进。
Work Design 的答案
笔者使用 Ruby On Rails 从事 Web 应用开发超过了 8 年，Rails 开发框架曾经引领了 Web 应用开发的潮流，一度其他开发语言的 Web 开发框架都或多或少的“学习”了 Rails 的理念。虽然在国内不是 Web 开发的主流，但是其理念依然领先于所有的开发框架，是独立开发者(One Personal)的开发利器。
曾经一度有人提出，Rails 是很适合验证商业模型的开发框架，用于前期快速实现。无论是适应“一个人开发”，还是适合验证模型，都是人们对其开发效率的认可。
从这个角度来说，Rails 好像和低代码平台站在了同一个战壕里，都在追求如何让 Web 应用快速实现。
而我们要让低代码开发破局的关键，也正在于让通过低代码工具进行开发和常规开发能够实现无缝衔接。
低代码开发所追求的，也无非是尽可能降低开发成本，让开发者写更少的代码，让开发者学更少的开发知识即可开展工作。
让开发者写更少的代码
1
2
3
4
5
6
# Model 层代码
class Account < ApplicationRecord
attribute :address, :string, index: true
attribute :owned_nfts, :json, default: {}
attribute :total_nfts, :integer, default: 0
end
1
2
3
4
# Controller 层代码
class Admin::AccountsController < Admin::BaseController
end
1
2
3
4
5
6
7
# View 层代码
# _index_thead.html.erb
<th><%= Account.human_attribute_name(:address) %></th>
# _index_body.html.erb 文件
<td><%= model.address %></td>
以上代码是我们真实项目中的例子，只需要定义模型包含哪些字段，及字段属性。定义 view 层展示的表头，已经展示哪些属性。就拥有了一个正常的后台管理界面。
通过可视化界面更改程序
除了在代码中进行定义，我们还具备在可视化工具中，定义模型的能力。