共计 2428 个字符，预计需要花费 7 分钟才能阅读完成。
开发人员的大量工夫花在构建外部零碎上
据国外的一份钻研报告显示，开发人员 30% 的工夫用来构建外部零碎。随着公司规模越大，这个问题会愈发重大，你能够设想一家领有 5000+ 员工的公司，开发人员破费近 45% 的工夫在外部零碎开发上吗？
来主动视暴雪员工技术分享（https://youtu.be/xCu73WVg8Ps），拳头产品的背地离不开多个外部零碎的协同反对
如果开发外部零碎是用来进步咱们的生产力，那么节约大量开发人员的生产力来实现它是否大失所望？
少数开发人员停留在「从头构建外部零碎」阶段
650 名开发者 / 技术 leader 中，约 2/3 的人仍在从头开始开发一个自定义利用（build from scratch）。同时，大家抉择的编程语言次要是 JavaScript、HTML/CSS、SQL、TypeScript 和 Python，抉择的框架集中在 React、Express、jQuery、Angular 和 VUE.js（jQuery 能在更新换代如此迅速的互联网时代仍旧受欢迎，应该是很多老公司仍在开发和保护遗留零碎的「功绩」）。
目前，低代码采纳者仍为多数，对于这些用户来说，这是一个正确并且违心持续采纳的抉择；然而对于剩下的大多数呢，随同着一种心理上的「高傲与偏见」，很多开发者对尝试低代码当机立断，他们更置信他们所面临的业务问题只能通过本人写下的一行行代码能力解决。
低代码的实质是在更高的抽象层次上开发
但纵观编程语言的倒退，无论是从机器语言到汇编，还是从 COBOL/FORTRAN/C 到面向对象高级语言，都是在朝着更高的抽象层次倒退。更高的抽象化，既包含开发者便于辨认、易于浏览、更合乎天然思维习惯，也意味着让人在应用这门语言时，可能更有效率地实现性能，达成业务指标。
当你在应用 React 开发一个 Web 利用时，那么相较于写 JavaScript 代码，你曾经站在「伟人的肩膀」上了 —— 用传统的 JavaScript 想实现雷同的后果，须要更多更繁琐的代码。试问，一遍又一遍地复制粘贴雷同的 HTML，还是迭代数组稍稍批改一下就呈现出雷同后果，如果是你你会如何抉择？
纯 JavaScript 与 React 实现一个长度为 3 的 <ul /> 比照，如果长度为 50 呢？
又试想一个场景：如果你的团队须要为公司的网站实现一个新的领取零碎，这个零碎可能提供像支付宝和微信领取一样弱小的服务吗？况且开发与迭代像这样简单又宏大的程序，须要大量的工夫、金钱和人力资源，等等；既然如此，咱们何不将这份工作代理到支付宝或者微信等其它三方领取平台，让它们帮咱们实现这件事呢？
天下文治，唯快不破，让研发能专一于业务逻辑，将艰巨、干燥的工作交给框架 / 平台来解决，这何乐而不为？
显然，咱们都在致力于缩小编写的代码量、进步开发效率、更加专一于业务逻辑而不是与底层技术细节缠斗。应运而生的低代码便是时代变动的产物。
回绝当 CRUD Boy
「外部零碎」的次要目标是企业外部信息管理，包含 BI 数据看板、Admin 后盾、数据录入零碎、客服零碎，等等。
这些零碎往往业务逻辑简单，研发们须要思考数据库的 CRUD 操作、UI 界面的搭建、交互的串联，此外还有一大堆成员治理、权限、审计日志，等等。在大多研发人员抉择「所有从头开始开发」的现状下，他们所投入大量的工夫精力可能都不是在解决真正的业务问题，而是在重复性的造轮子以及大量粘合代码、模板代码中。
相比干燥反复的工作，置信大多数人更想去解决乏味的事件（建模并解决理论业务问题）。重复性 CRUD 曾经走向末路，低代码利用开发时代曾经到来。
写在最初
作为开发人员，很多人心愿对咱们开发和保护的货色领有所有权，当他们被调配一项应用低代码平台拖放（drag & drop）加大量代码就能够实现的工作时，他们或者会感觉本人不再是一名「真正的」程序员。相似的问题像是网上常常会有人探讨应用可视化编辑器 WordPress 的人是否是一名「真正的」程序员，应用 Shopify 疾速搭建电商网站的人是否是一名「真正的」程序员…… 这种状况不可胜数，但咱们对这类问题的答案很简略：是的。
我抉择低代码，与此同时我深信本人是一名「真正的」开发者，因为正如在「低代码的实质是在更高的抽象层次上开发」这一章中提到的，如果没有站在「伟人的肩膀」上，我很难独立从头开始敲代码。NASA 的玛格丽特·汉密尔顿，一位平凡的软件开发先驱，她所写的代码量用纸质模式出现足足有一人高。可现在咱们有多少人能做到这样呢？这难道就意味着咱们不是「真正的」开发者了吗？我不这么认为。
玛格丽特·汉密尔顿，程序员版本的「著作等身」，图源：https://news.mit.edu/2016/sce…
此外有一种景象叫「宜家效应」，是指消费者对于本人投入劳动、情感而发明的物品，产生高估的价值判断偏差的景象；这解释了为什么即便有更好、更简略的代替计划，很多研发仍会抉择从本人的敲下的一行行代码中取得很多成就感。因而，越来越多的低代码平台，如码匠、海内的 Appsmith、Retool、Budibase 等，也开始留神到平台的可编程性、可扩展性与灵活性，并一直摸索最佳实际，力求为程序员提供更多的施展空间，让他们享受「宜家效应」所带来的高兴。以码匠为例，咱们在保留了低代码高度抽象化个性的同时，提倡「到处可写 JavaScript」：「{{}}」中的语句都会被执行为 JavaScript 代码并在沙箱（Sandbox）中执行；咱们也反对模块化（Module）编程，你实现的代码块能够疾速为团队其余成员复用……等等。
码匠「{{}}」中的语句会在 JavaScript 沙箱（Sandbox）中执行
码匠简直能够在任何中央通过编写 JavaScript 解决理论业务问题
浏览到这里，如果还有人问我如何对待低代码，我可能会这样来反诘 Ta：假使有五个开发人员，你是违心让他们五个从头开始，全职开发与迭代一个外部零碎，还是抉择一个低代码工具，让其中一位去开发它，其余四位来开发公司的理论产品呢？