挑战来自那里？
在之前的文章《聊一聊低代码产品的分类》 中介绍低无代码的两种产品形态及其抽象层次上的差异，介绍了低代码本质上是一个基本符合软件工程规范的应用编程和运行系统。
因此我们可以将低代码系统拆解成一个应用编程系统 + 一个应用托管平台系统。得益于这几年云原生领域的快速发展，依托云原生技术栈搭建一个集应用部署、运行和运维功能在内的托管平台挑战并不大，不少云原生企业已经提供给了相对标准的产品。网易低代码平台也封装提供了一个应用托管平台系统。
低代码平台建设的复杂性挑战主要来自于对“应用编程子系统”的设计和实现两个方面。我们从两个视角来解读：第一项挑战，从产品技术视角可以被表述成：
- 在没有参照情况下，如何设计全栈编程框架和配套框架的编程语言，才能做到“编程门槛足够低，上限足够高”？
切换成组织管理视角，可以被表述成：
- 传统的互联网或软件产品设计人员缺乏编程框架和语言设计的知识和经验，如何培养或找到有编程框架和语言设计能力、又有产品素养的复合型产品专家，并驱动他们设计出优秀的低代码编程框架和语言？
第二项挑战，从产品技术视角可以被表述成：
- 如何设计该编程框架和语言的实现架构，使得框架和语言在持续迭代、演进的过程中能保持实现架构和实现质量的稳定？
切换成组织管理视角，可以被表述成：
- 如何组织一个人数逐渐增长的产品技术团队，使得每个小组（甚至每个人）的工作足够专业和聚焦，同时各小组又能密切配合，确保产品研发的效率和质量。
如何应对这两个挑战？要应对第一项挑战，可以从三个方面着手：
- 首先要解决创造性从何而来的问题，主要从人的角度去解决。“如何设计全栈编程框架和配套框架的编程语言”对低代码平台而言，属于产品设计领域，是产品经理要解决问题。但传统产品经理往往不具备编程知识，但低代码的产品设计又需要在框架和语言层面上张开维度，因此就需要从研发团队培养或者通过招聘引入外部的编程框架和语言设计专家。
- 其次需要配套合适的管理制度，确保个人想法和组织目标保持一致。比如可以成立编程框架和语言设计提案评审委员会（参考https://github.com/vuejs/rfcs），通过提案评审机制一方面可以鼓励大家提案激发创造力，同时又能有效的控制编程框架和语言的演进。同时这个机制的确立也明确的把编程框架和语言设计作为低代码团队第一性的设计任务提到了首要的位置，有很强的牵引意义。
- 第三，全栈低代码编程框架和语言设计是一种创新，既然是创新就可能有偏差，所以越是创新就越需要寻找或制定科学的、清晰的度量、评价的框架，依靠评价框架客观完整的反应用户真实的使用体验，然后形成正向改进的循环，才能把创新做好。
1. 网易轻舟低代码项目自2020年立项之初的一年多时间里一直没有产品经理，一直是几位经验丰富的研发同学在做产品设计。21年下半年我们招了第一位专职的产品经理，22年我们又把2位优秀的研发划到编程框架和语言设计（产品）团队，并且从外部引入了2位编程语言设计专家。自此产品设计团队才从游击队变成正规军。2. 2022年初成立了NASL语言设计提案评审委员会。（详见：http://nasl.lcap.group/docs/current/contribution/process）3. 2021年低代码产品顾问邓际锋老师推荐很有价值一篇paper《Usability Analysis of Visual Programming Environments: A ‘Cognitive Dimensions’ Framework》(详见：https://web.engr.oregonstate.edu/~burnett/CS589and584/CS589-papers/CogDimsPaper.pdf），此后我们用研团队以此为基础制定了用户体验评估框架并定期开展用户体验调研评估，输出了很多有价值的改进意见。
第二项挑战更有意思。考虑到看这篇文章的大部分人可能是互联网技术人员，首先可能需要解释一下，为什么用传统互联网产品研发组织模式不能很好解决低代码编程系统研发的需求的问题，其实我们也是走了很多歪路才得到的教训。
下图这种经典互联网产品研发组织模式基本可以解决大多数的互联网产品研发需求，而且正是因为如此，这些岗位事实上成为了互联网行业的标准技术岗位。
- 由于网易低代码团队成员都是互联网、云算计产品研发背景，另外也由于立项之初没有足够的合适的人力资源，所以很长一段时间都是按照上面的模式来开展研发。这种模式最大的问题：
- 产品设计、研发实现专业性不足，导致很多摩擦多走了很多歪路。参考《关于“低代码应用是否需要强制划分出前后端两类服务”的思考》、《轻舟低代码产品化进阶之路》。
- 岗位设置专业性不足。按照上述传统岗位要求招人，招不到合适的专业的人才；在人才使用和培养方面也缺乏有效指导和牵引，培养不出专业的优秀的人才。
- 组织设置跟产品功能架构或实现架构都不对齐，组织内部沟通损耗多，迭代开展困难，质量不受控。
最终我们认知到，只有做好了编程系统实现架构的设计，才能解决产研团队有效组织的问题（参考康威定律）。经过了2021年频繁的产品设计和实现架构调整之后（详见《轻舟低代码产品化进阶之路》）低代码平台的实现架构逐渐往经典的编程语言架构靠拢（详见《聊一聊轻舟低代码NASL编程语言》），这个架构较为清楚的定义了专业的组织分工。
在上述实现架构逐渐成型之后，遇到主要问题有两个：
- 没有足够的专业研发人员负责这么多模块设计研发。
- 质量不受控。主要有两个原因：一是特性拆解、实现不到位；二是质量评估遗漏。
第一个问题看上去比较好解决，但实际上争取预算和找到合适的人并不容易。首先需要站在老板角度考虑研发分工过细可能导致的研发成本飙升和浪费的问题，其次国内做编程框架和语言研发方面的人才不太好找。第二个质量不受控的问题则更具挑战，为了更好的解释这个问题，我们把图画的完整一点。
这里涉及到互联网架构软件系统两个典型的特点：一个是产品功能设计和实现架构背离：产品功能设计面向用户（多变），实现架构设计面向稳定；另外一个典型特点是敏捷式开发，要求小步快跑的方式改进用户体验。在这个体系里，架构师的角色就显的异常重要，他不仅要定义实现架构并使其尽可能保持稳定，而且要将各种逐渐迭代的框架和语言特性、平台功能特性拆解到实现架构上去。如果架构设计不合理、或者特性实现拆解不到位，就会导致各种质量问题。但实际上我们很长一段时间没有清晰定义架构师岗位和职责，这个导致了所（没）有人对此负责，出现了实现架构不稳定、特性拆解不到位导致的各种质量问题。
明确了产品和语言设计、架构师和研发这三种角色，尤其是把架构师岗位定义出来后，带来的好处是比较明显的，使得各自的工作相对能够聚焦。从“图三”到“图五”，我们从一个普通互联网产研团队，逐渐转变成了一个相对专业的低代码研发团队。但是，按照“图五”的分工还遗留了如下三个问题：
- 对架构师要求比较高。“图五”的分工非常依赖于架构师的能力。架构师需要定义包括编程系统和应用托管系统内各模块的职责、模块间的接口；任何平台或编程语言特性的引入或调整都需要依赖架构师拆解到模块、增加或更新模块间接口。架构师既要懂编程语言设计和实现、又要懂云原生技术体系的平台子系统的设计，职责范围的广度，使得架构师难于把控设计细节。
- 模块（组织）拆解过细，导致上层管理问题浮现。一个并不复杂的问题，往往需要拉多个团队协作处理。从管理的视角看破坏了方案设计的完整性，割裂了问题处理的连贯性。
- 按照“图五”方式，平台所有的特性和需求统一排期，导致应用托管系统相关的一些需求一直延后，产品完整性受到影响。
如何解决上述这些问题，这时候就需要用到复杂度降解的经典的方法：子系统拆分。
子系统拆分最核心的一点原则是“功能”和“实现”要能聚拢在一个子系统内，达到功能边界清晰、实现低耦合的目标；
根据这种思路我们将低代码功能和实现架构做了如下的拆分：
这种拆分的优点是将一个复杂系统拆解成了4个相对独立的子系统，降解了子系统复杂度，并且实现了低耦合（子系统层面做到了功能架构和实现架构的统一）。
- NASL语言及配套语言工具不依赖其他模块，提供NASL规范检查、编辑提示和翻译到其他GPL的基础能力。
- 平台只依赖外部服务，为用户提供应用元数据的管理、应用监控和数据运维能力，为集成开发环境提供应用集成信息的管理、应用部署等能力。
- 资产中心不依赖其他模块，提供扩展依赖库生产（脚手架）工具、依赖库和模版等资产的托管能力。
- 集成开发环境面向用户提供UI操作环境，依赖NASL配套语言工具、资产中心和平台提供的接口，实现NASL编辑、调测和存储。
- 按照子系统来配置产品研发团队，避免了分工过细可能导致的研发资源浪费问题，同时有能保证研发岗位专业知识聚集，对人员招聘和培养起到指导和牵引的作用。
- 子系统划分缩减了子系统架构师的职责边界，能让架构师更专注解决本领域的架构和特性设计，提升平台和语言特性交付的质量。
- 降低了上层管理的难度，一些领域内方案设计和实现的问题，能在本领域内得到完整高效的解决。
- 平台子系统功能迭代不用跟编程子系统去竞争资源，保障了平台功能的迭代进度和产品完整度。
至此，整个产品研发团队的组织就有了章法。能使得每个小组（甚至每个人）的工作足够专业和聚焦，同时各方又能密切配合，确保产品研发的效率和质量。
第二项挑战实际上是通过确立相对稳定的系统实现架构和子系统拆分来指导组织架构分工的过程。产研团队的管理者，往往需要承担起顶层架构师的职责。系统设计的目标是定义系统中每个模块的职责，各个模块按预期运行就能保证系统的正常运行；对应的组织管理的目标就应该是定义清楚每个小组（甚至每个角色）的职责，使得每个小组（角色）做好自己的工作，就能完成组织的目标。企业选择软件平台类产品，通常看重平台的成熟度和供应商稳定的研发能力，这需要靠组织能力和制度来保证，具体一点就是合理的组织架构分工+严谨的流程。华为ipd流程能推动运营商业务发展，是因为ipd配合各条产品线组织架构，做到了即使有很多层团队，但只要每个团队（甚至每个人）只要做好自己的本职工作，就能达成整个产品特性研发交付的目标。所以组织和流程是稳定产出的保证，是全球运营商信任华为的原因。此外，虽然华为倡导“以奋斗者为本”企业文化，但是他的组织架构却是以防范人的惰性为基础设计的，有着非常清晰的组织职责的划分。所有的管理理念要互相支撑形成体系才能发挥作用。
总结 这篇文章主要分享了低代码平台建设中遇到的两项挑战和我们的应对思路。第一项如何设计低代码编程框架和编程语言的挑战，要从人、制度和创新评估手段三个角度去解决。第二项，如何组织低代码平台产研团队的问题，要从实现架构和子系统拆分的角度去解决。低代码编程系统作为一个开发软件的软件系统，他的产品功能体现编程框架和语言的设计，实现架构按照编程语言的架构，从我们目前已知的知识体系看来是比较合理的。不过著名物理学家普朗克说过，科学是内在的整体，他被分解为单独的整体不是取决于事物的本身，而是取决于人类认知能力的局限。我们要承认认知是有局限的，我们能做的是就阶段性的局限形成共识、减少摩擦，同时在取得认知突破后，要有调整的勇气。只有这样，才能更好的应对挑战。
