《低代码指南》 低代码开发平台的职责与挑战是什么？ 是否就一定要如阿里云所主张的那样，“把复杂留给自己，把简单留给别人”？虽然这句话听起来很深明大义，但不知道大家有没有想过，为什么我们一定要抱着复杂不放，平白无故给自己找事？就不能直接干掉复杂，也给咱阿里云自己的员工留点简单吗？是工作太容易就体现不出来KPI价值了，还是家里的饭菜不如公司的夜宵香？

冥思苦想许久后，我从热力学第一定律中找到了答案：开发一个应用的总复杂度是恒定的，只能转移而不可能凭空消失。要想让开发者做的更少，安心享受简单的快乐，那么平台方就得做的更多，默默承担尽可能多的复杂度。就像一个满身腱子肉的杂技男演员，四平八稳地托举着在高处旋转与跳跃的女搭档；上面的人显得越轻盈越毫不费力，下面的人就得越稳重越用尽全力。当然，不是说上面的女演员就很轻松没压力，只是他们各自的分工不同，所承担的复杂度也不一样。

根据《人月神话》作者Fred Brooks的划分，软件开发的复杂度可以划分为本质复杂度（Essential complexity ）和偶然复杂度（Accidental complexity）。前者是解决问题时固有的最小复杂度，跟你用什么样的工具、经验是否丰富、架构好不好等都无关，而后者就是除此之外在实际开发过程中引入的复杂度。通常来说，本质复杂度与业务要解决的特定问题域强相关，因此这里我把它称为更好理解的“业务复杂度”；这部分复杂度不是任何开发方法或工具能解决的，包括低代码。而偶然复杂度一般与开发阶段的技术细节强相关，因此我也相应把它称为“技术复杂度”；而这一部分复杂度，恰好就是低代码所擅长且适合解决的。

为开发者尽可能屏蔽底层技术细节、减少不必要的技术复杂度，并支撑其更好地应对业务复杂度（满足灵活通用的业务场景需求），这是身为一个低代码开发平台所应该尽到的核心职责。

在尽到上述职责的同时，低代码开发平台作为一个面向开发者的产品，还需要致力于为开发者提供简单直观的极致开发体验。这背后除了巨大的工作量，还得能在“强大”和“易用”这两个很难两全其美的矛盾点之间，努力找到一个符合自己产品定位与目标客户需求的平衡点 —— 这也许是设计一个通用低代码开发平台所面临的最大挑战。