低代码这个名词说起来已经有些年头了，广义上来讲可以说是达到这么一种效果，即尽量减少通过编写代码的方式来完成研发任务，甚至部署交付整个技术产品。那么低代码模式到底值不值得弄，有什么优势和缺陷，本篇文章笔者就来聊一聊自己对于低代码的一些思考跟想法。
做技术的都知道，实际工作场合上，不能为了技术而技术。低代码也是一样，这门技术最重点解决的问题是，让不懂代码的人可以通过一套工具来完成自己开发的作品，所以从产品角度，低代码工具应当更加倾向于提升易用性，而非提升功能性。假设我要开发一个服务，我手写代码+手动部署需要3天，而学习低代码工具+完成服务搭建只需要1天，那么这种情境下，低代码工具就能够兑现自己的价值。
所以低代码模式值不值得弄，最先决的条件是，低代码所应用到的领域产品，是不是通过写代码的方式工作量非常大。好比说，我要渲染一些图形，那么就需要涉及复杂的数学计算，直接敲代码是非常困难的，但如果我有一些低代码工具，可以通过运算节点之间的关系描述计算过程，那么我就可以通过一些图形的拖拽，就可以达到渲染图形的目的。UE、Unity之类的游戏引擎都是这样做的，通过图形化的视图操作，减少了游戏开发者的工作成本。对于游戏、仿真领域而言，有时候不必做到非常严苛的效果，通过正向的运算流程意思一下即可，因此图形化的逻辑描述可能并不没有想象中那么复杂，反倒是正常的业务后端逻辑，充斥了很多防御性代码，并且可能链路比较长，这类场景就不适合用图形化的方式描述逻辑。
低代码模式要兑现价值，还有比较客观的因素是，所应用到的领域需要有一定的用户基础。低代码工具的维护量是非常大的，首先底层需要对代码本身以及业务流程之类的节点做封装，起到一个宏的作用，然后上层还需要做流程节点的图形化展现，并且还要做的美观易用，以尽力减少代码编写、节点配置以及领域理解成本，这些不是简单三五个人就很快做出来的，而且也得做的美观做的稳定才能够交付用户使用，否则用户也玩不转。如果说低代码工具所配合的产品用户量不大，那么即便做成了，时间成本也不一定能够被用户收益打平。从企业运营的角度来说，这一部分工作量还不如用来做更有价值的事情，比如对其他领域的产品创新，或者是已有产品的技术复用。
总的来说，低代码开发模式值不值得做，从技术上讲肯定是值得的，对于用户的收益是很明显的，但从企业运营还有研发团队发展角度来说成本会比较大，即便有用户收益也不一定能够抵消成本。所以如果要投入做低代码工具，最好产品本身有一定的用户基础和技术生态基础，这样才能锦上添花。