04 演进策略：先发展通用能力还是先满足业务需求？
你好，我是陈旭。今天我们来说说低代码平台在不同发展阶段的不同演进策略。我们可以将低代码平台的发展过程划分为3个主要阶段：MVP阶段、成熟期、超越期。
MVP阶段一般在3到6个月，时间比较短，主要目的是快速试错、快速闭环。这个目的之外的工作一般都“先放一放”，因此这个时候，备忘录里往往会留下许多待改进条目，但这些欠债在成熟期都要一一偿还。性能问题实际也是一种欠债，单独拎出来说是因为性能问题往往比较麻烦。它是慢性毒药，当毒性呈现出症状时，哪怕是轻微的症状，基本都已经很难搞了。而且，性能与功能是相生相克的，功能追加到一定程度就必然要停下来专门处理性能问题，两者呈现出一种螺旋式上升关系。
成熟期是实现低代码平台过程中的一个比较艰难的阶段。随着MVP阶段的需求免疫光环褪去、天使用户开始介入，实际业务需求紧跟着也就来了。此时平台团队往往面临这些直接压力：
- 偿还MVP阶段的欠债；
- 彻底解决性能问题。
功能欠债也好，性能问题也罢，始终只是技术问题。熬熬夜，牺牲一点发际线总是可以解决的。更麻烦的是，随着低代码平台的实际应用的推进，在MVP阶段中被有意无意忽视的业务场景逐渐显露出来，变得越来越具体。
这个状况会把低代码平台的发展道路的抉择推到风口浪尖上：先发展通用能力还是先满足业务需求？
其实，先发展通用能力也好，先满足业务需求也罢，最终目的是一致的，都是着眼于解决实际业务问题。这里的关键是优先发展哪种能力，是着眼于长远，还是着眼于眼下。
而到了超越期，我们的目标就非常明确了：解决具体业务问题，将业务问题梳理为各种场景，然后针对场景做针对性优化，使得在已覆盖的场景里的开发能力、效率等各方面全面超越Pro Code模式。
即使是在未覆盖的场景或者特殊场合，低代码平台也可以通过部分回退到Pro Code模式的手段、采用高低代码混合的方式，实现对业务开发需求的支持。并保持效率、交付能力相对Pro Code模式的优势，从而达到低代码平台将在各方面显现出对传统Pro Code模式的全面超越效果，这显然是振奋人心的一个阶段。
通过前面对各个阶段简单的分析可以看到，MVP阶段和超越期的线路和目标非常明确，我们不需要过多讨论。但成熟期却有两条相对清晰且都很有说服力的发展路径：先发展通用能力还是先满足业务需求。这正是我们这一讲要解决的问题。
选择什么样的发展路径？
这个问题的答案实际上没有太多的悬念：优先发展通用能力。
“通用能力”指的是一种不与某种具体业务绑定的开发能力，是一种能够适用于各种形式业务的开发能力。在这里，我无法给通用能力画一个边界，或者给出一个精确的定义，因为它有很大的弹性，它的边界只存在于每位平台设计者对业务的理解中，或者说在他们的心中。可以说，你对通用能力的边界理解和想象，大概就是你的低代码平台未来的能力上限。
作为一个开发平台，哪怕只是一个开发工具，如果能力过于聚焦，带来的后果会是很难适应不断变化的业务需求，也很难搞定新形态的业务，从而失去拓展新应用领域的机会。最终的结果就是要么是推倒重来，要么就是被其他通用性更强的平台所替代。
毕竟，人人都希望有一个具有更多想象空间的平台，而不是只顾眼下的一亩三分地，一眼就能看到它的边界。想象空间越大表示它能做的事情越多，潜力也就越大，相应地，它能给你的回报也会越大。当你自己对这个平台的能力都没有想象空间的时候，就不可能让别人（上级或投资者）对它有多大的期待，这样就几乎不可能获得更多的资源。
所以，如果非要给“通用能力”画个边界，你对它的想象空间就是这个边界。而你对它的想象空间也决定了别人（上级或投资者）对它的想象空间，从而决定了它能给你带来多少资源和回报。
那么，不走优先发展通用能力的道路，还有其他发展道路可以走吗？
有的。我们可以选择优先聚焦于业务场景和业务痛点，优先发展能快速解决当前业务问题的开发能力、能切实解决业务痛点的能力。仔细想一想，这样的发展线路不但没有问题，而且会显得很务实。从实际问题出发，并且在短期内可以获得成效。
但是过于聚焦的实现往往意味着扩展性不足。一个显而易见的后果就是难以适应后期业务场景的变化，那当这样的状况出现时，要怎么办呢？
有人说：简单，再针对新的业务、新的痛点重新来一次就好了。但如此反复数次后，一个新情况马上就出现了：
这张图就表示了这个状况。你可以看到，每次都从头开始，在短时间解决具体问题的能力确实能迅速爬升，见效快。但由于没有通用性，在最初设定的业务问题都解决了后，自然就到达顶峰，之后基本就没下文了，每个工具都是这样。
如果你是一名管理者，你最容易想到的，可能是如何整合已有的这些工具。一般在评估之后，你会发现这很难！
因为这些工具是由不同的人在不同时间，采用不同方法（Shell、Native App、Web）聚焦在不同问题上开发出来的，简单地说，他们没有共同的基因。更要命的是，这种解决问题的思路形成习惯和传统之后，你会发现无论时间多长，能力的上限基本就在那，没有任何想象空间。显然谁都不希望看到这样的结果。
现在，我们可以来尝试回答一下这个小节标题中的问题了，你应该选择什么样的发展路径？很显然就是走优先选择发展通用能力的路。越通用，想象空间越大。
坚持优先发展通用能力不动摇
但凡事总有两面性。通用是有代价的，它的代价就是不能聚焦于具体业务，从而导致在具体业务上没有很好的表现。甚至，还有可能在开发特定业务的情况下，和传统Pro Code方式相比，不仅没有任何改进，甚至还倒退！
这与低代码模式四处标榜的高效、简易等标签相悖，很多低代码的反对者将这些案例收集起来作为毒瘤论的例证。
这里，我放了一张图，展现了优先发展通用能力的工具/平台的发展过程：
你可以看到，MVP阶段与其他工具相似，只是周期很短，短时间内也有能力的迅速爬升。成熟期相对漫长，而且具体业务开发能力缓慢爬升，基本处于啥都差一点的状态。这个时期注重的是发展通用能力，为未来的各种场景做架构设计和打基础、解决性能问题。但这个阶段往往很容易夭折，不仅因为这个阶段难度巨大，而且漫长的持续投入与看到的收益不成比例。
如果你刚好是负责人或直接领导，在这个阶段里应该要不停地讲故事，把你的想象空间尽可能形象地描述给上级或投资者，建立他们的信心。能由此获得更多资源是最好的，但至少不要被压缩现有资源。同时也帮他们建立想象空间，让他们去影响他们的上级。
成熟期的一个显著特征是待实现的多数业务都会触及低代码平台的能力边界。所以几乎每面对一个新需求，你都要接受这样的灵魂拷问：要如何在确保平台的通用能力得到扩展的前提下顺便满足当前需求？即使通用能力无法得到拓展，至少也要避免为了实现某个业务团队需要的开发能力而将该具体业务耦合到平台中。
我的建议是，请按顺序评估如下的因素：
- 评估手里有多少可用资源，这是根本；
- 评估当前用户的友好程度；
- 评估老板或者你自己有多强势，面临业务压力时，他能扛住多久。
资源是一切的根本。资源充裕时，你基本上可以忽略其他任何因素。但资源总是有限的，需要着重考虑的是当各方扛不住业务压力时，有没有备用资源可以投入，以缓解矛盾、快速提供业务需要的开发能力。那些开发能力和效率都值得充分信赖的、又肯熬夜加班的技术骨干，就是一种王炸级别的备用资源。此外，你还要仔细避开那些与投入资源数量无关的困境，比如前面我们提到的性能问题，或者所用技术大大超出已有储备。
平台的用户（即业务开发人员）的友好程度也是一个重要因素。通用的能力往往无法在具体业务开发场景中提供良好的易用性或效率，而难用和低效是需要由他们来直接承受的。因此，如果用户群体的友好度很低，他们三天两头地发邮件，还在各个场合下不余遗力地抱怨，我相信你或者你老板很快就会妥协。在面对低友好度用户的时候，我们就要适当地聚焦在他们的痛点上，而不能一味追求通用能力，反之则可以更多地聚焦在通用能力的研发上。
你或者你老板有多强势是另一个因素。如果出问题时、业务团队不停抱怨时，总有人为你站台的话，你就可以更加专注于发展通用能力上。但这时我们要学会讲故事（画饼），不失一切时机地将通用能力所构筑的想象空间描绘出来。
坚持优先发展通用能力的道路的收获季，是在场景化阶段，也就是超越期。在一个通用的底座之上支持某种具体场景是很容易的，因为此时你考虑的已经不是能不能做到的问题（这个问题在成熟期已经基本解决了），而是要不要做、做成啥样的问题。即使做错了，付出的成本也只是把该场景推到重来而已，并不需要将整个平台推到重来。
这就好比我们国家坚持先发展重工业，后发展轻工业。在重工业阶段投入巨大、艰苦卓绝，但当各个工业门类基本建设齐全之后，再发展轻工业就相对容易得多了。结果有目共睹，近20年我国的GDP嗖嗖地往上涨。
一旦确定如何实现某个业务场景之后，实现的方法基本上都是一样的：具体化和自动化。
具体化和自动化实际上说的是同一个事情，场景越具体，配置内容也就越具体，越具体的配置内容就越容易实现自动化。这里所谓的自动化，指的就是在具体的业务场景下，基于通用能力自动化生成各种各样的配置。场景越具体，自动生成代码的比例就越高。而自动化完成几乎所有业务的开发，不就是低代码的魅力所在吗？
到了场景化阶段，低代码的魔力才开始显现，才能真正拉开与Pro Code模式的差距。这两种开发模式的能力终究会在某个点上出现交叉：
并且，一旦Low Code模式的能力超过Pro Code模式之后，这个趋势终将不再回头。因为此时的Low Code模式将依托于其强大的通用能力，将各个场景逐个纳入到其能力范围内。每个被支持的场景生成的代码都凝聚了技术专家、业务专家的智慧，因此，一旦低代码平台支持了某个场景，凝聚其中的专家经验将持续为高/低各种技能水平的使用者赋能和提效。这是Pro Code无法做到的。
而Pro Code模式，它固有的内秉性知识传递的弊端、以及语言自身能力的限制，导致它的能力上升将极其缓慢。这点你从身边的编码专家身上就可以看到，他们写了十几年代码，却依然摸不到这个领域的天花板，更别提有所突破了。Pro Code模式的业务交付能力，之所以能随着时间推进持续缓慢爬升，是因为团队人员（不考虑流失）的编码经验在缓慢地提升，但显然靠个人经验的提升来提升业务交付能力的边际收益，必然是越来越低的。
如何保持优先发展通用能力呢？
前面说了，“通用能力”指的是一种不与某种具体业务绑定的开发能力，是一种能够适用于各种形式业务的开发能力。当低代码平台仍处于成熟期时，待实现的多数业务开发能力的需求，都会触及低代码平台的能力边界，我们需要创造出新的能力来拓展平台的能力边界。而且，用于拓展能力边界的功能都要是通用的，而不能只适用于当前的具体业务。
这样讲比较抽象，接下来我讲一个我自己的实际案例，帮你加深理解。
第一个例子是关于大场景的需求。在MVP阶段甚至更早的时候，我们的业务团队提出了两个比较典型的应用场景：一是低代码平台需要能支持表单的可视化开发；二是低代码平台需要能支持Dashboard的可视化开发。
这两个需求本身其实就已经具有很高的通用性了，直接照做也无可厚非。但深挖下去，你会发现这样的问题也需要一并解决：
- 极少有表单单独成一个App的（否则就变成调查问卷了），表单与表单之间如何串联？
- Dashboard里也有可能使用表单，有的Dashboard会有查询条件，查询条件部分就是一个表单（这在我所在的产品里很常见）。
为了能同时解决这几个显式和隐式问题，低代码平台最起码需要提供一个能同时支持表单、Dashboard，以及它们相互引用的功能。实际上，能满足这样功能的编辑器的通用程度就已经很高了，再考虑到其他可能出现的应用场景，我们很容易想到需要打造一个不以任何具体场景为假设前提的场景编辑功能。后来我将这个场景称为通用场景。
第二个例子是关于图形的需求。应用团队提出需要提供柱状图、折线图、饼图、仪表盘等常见图形的可视化编辑功能。其他常见的图形还有散点图、漏斗图等不下10种图形。
这里需要说明一下背景，我是echarts来绘制图形的。对它有一点了解的人都都知道，echarts不仅可以绘制这10来种常见图形，也能绘制其他许许多多不常见的图形。
每一种图的配置方式差距非常大，挨个去定制的话基本等于做10个独立的图形，但需求又非常多，我们不可能一个个去定制。于是我决定先提供一个支持任意图形的开发能力，而不提供可视化方式。当然，这事是先要和应用团队沟通的。这样做的话，短时间内可以满足业务团队对图形的任何需求，而我也可以将资源投入到其他功能的开发。
其实类似例子有很多，但这两个案例已经足以说明问题了，现在来总结一下我在这样的情况下的方法：
- 对业务提交的任何功能需求，都按照最通用情形来考虑。即使对方只要一棵树，仍按照一座森林来考虑，我们不见得就要实际交付一座“森林”，但要为它预留足够的位置；
- 充分考虑已知场景的共同特征，暂时把它们的个性化特征丢角落里。过多考虑个性化特征只会限制你的想象力，这会牺牲掉许多易用性，但这是权衡之下必要的取舍，这是通用的代价。
还有第3点，是上面两个实例没体现出来的：
- 任何业务需求，只要能采用已有的功能实现的，决不新增功能；只要保持已有功能通用性不变前提下稍微扩展就能实现的，也决不新增功能；好钢用在刀刃上，资源集中投放到开发新的通用能力上，不分散。
还有第4点，是非技术性因素：
- 之所以我能坚持这么做，是因为我的用户群友好程度较高，主要得益于我平时注重提升他们的满意度：倾听他们的痛点，主动热心协助解决问题（编码、出方案等），帮助他们脱困；一般只要他们的自身的需求能按时交付，他们就会很高兴；记住：放低姿态。
采用上面总结的4点咬牙坚持一段时间，大约12到18个月后，基本就可以熬过成熟期了。此时你会发现你的低代码平台基本上啥业务需求都可以实现了（虽然采用的实现方法没有像传说中的低代码那样酷）。但这意味着你的平台已经活下来了，并且有了一定应用基础，可以考虑进入了超越期了。
现在我们就可以充分聚焦到各个场景的个性化需求上了。这时我们再回顾下前面那两个实例。
通用化场景下表单的开发非常繁琐，数据采集后的所有校验都需要应用自己捕捉事件，自己编写校验逻辑。小到文本是否过长过短，大到服务端异步校验，都非常繁琐。那么我们可以针对表单的特性设计出新的配置流程，把校验逻辑全部自动化实现。应用只要填写校验规则和出错提示文本就可以了。
通用化场景下的Dashboard，无论是布局还是交互也都非常麻烦。现在我们可以针对它设计一个基于卡片的布局器，交互也可以简化成单传参和获取数据。这样，一个图表甚至都可以不用去关注其他图表，也能实现联动效果。
通用化的图形实现，实际上就是直接填写echarts options。这个门槛很高，需要学习echarts的大量配置API。那么现在我们就可以针对常见的图形，设计出针对性的可视化配置方式，屏蔽掉绝大部分echarts配置细节，做到只要会填表单就能开发出复杂图形。
那为啥一开始不这么做呢？资源！
当我们手里没那么多资源可以同时铺开时，我们既要保证新场景的支持不至于耽误应用团队的工期（这是最容易被投诉的因素），同时又要把已有场景做得很完美，这是需要大量资源的。实现一个通用能力，可以同时解决掉许多业务的开发需求，但如果我们把相同的时间投入到某个场景，即使做得尽善尽美，那也只能解决那一丢丢需求。我前面就说过了，在资源充裕的前提下，基本不需要考虑方式方法，干就完了。但现实的资源总是有限的，我只能这么做。
在超越期，场景化完善之后，是否通用场景就没用了呢？绝不是！
这些通用场景会华丽地转职为兜底策略的一部分。我说过，再完美的低代码平台也总有能力边界，总有业务团队提一些“奇葩”需求越过这条线。此时通用的功能就可以发挥兜底的作用，让应用能按期交付的同时，也给平台团队喘口气的时间。我们甚至可以根据这个需求的“奇葩”程度决定是否要无视它，即使这个需求下次再来，我还是有办法治它的。这就是兜底策略给的底气！
总结
今天我详细讨论了低代码平台演进策略，将演进过程分为三个主要阶段：MVP阶段、成熟期、超越期。针对成熟期和超越期的发展策略，给出了不同的侧重。成熟期侧重于发展通用能力，而超越期侧重于发展场景化和提效的能力。
成熟期是一个相对漫长的，比较难熬的阶段。在资源不充裕的前提下，为了着眼于长期演进，必须坚持优先发展通用化能力的思路。对业务提交的任何功能需求，都按照最通用情形来考虑，同时充分考虑各个场景的共同特征，而暂时忽略他们的个性化特征。坚持采用已有功能来实现各种需求，通过这个方法倒逼已有功能的进一步通用化。同时我们也要放低姿态，注重培育和改善与应用团队之间的关系，还可以与UX团队保持良好通畅的沟通，要求他们不要设计出一些超过当前能力的应用出来。
到了超越期，我们的重心就要转移到各个功能的个性化需求上来了，此时要把个性化需求和易用性提升到最高优先级。必要的话，甚至可不惜重新设计各个具体场景的开发流程，以获得更高的自动化开发水平，尽可能高地提升代码的自动生成比例，从而最大化地发挥低代码的开发优势。而此时在成熟期留下来的诸多通用能力，就成了平台的兜底策略的一部分，可以兜住场景化所未能覆盖到的那20%的场景。
思考题
- 低代码平台发展过程中的成熟期非常关键，这个阶段的发展质量基本决定了低代码平台整体质量，你认可这个观点吗？为什么？
- 除了这一讲提到的Dashboard场景和表单场景，你认为还有哪些场景与低代码技术是“天作之合”？完成了与低代码的结合之后，将对你现在的业务产生什么样的效果？
期待在留言区看到你的想法。我是陈旭，我们下节课见。
- 王小文 👍（18） 💬（3）
总结得真好。 我13年创业想打造的产品，当时想做的最终形态就是作者上一节描述的那个天花板模型。作者说的每一点都打到我心里。 这一节描述的通用性和业务定制化也是我们当初矛盾过的两难问题，当时mvp阶段，不知道到底是运气好还是运气不好，拿下了一个百万级的客户项目。甲方it负责人由于认可低代码理念（当时是2013年，我们都不知道自己做的东西叫做low code），给了我们充分的耐心。但再多的耐心始终敌不过需求部门的压力。由于我们担心自己变成“毒瘤”，担心项目黄了，担心现金流断了（当时拿了预付款之后立即做了人员扩招），最终妥协了，放弃一开始定下的通用化策略，投入许多人力做定制化。 慢慢的，产品被带偏了，我们花了许多人力去满足业务需求，但由于mvp阶段底座的不不牢固，以及核心开发人员的分心参与，我们做出来的“定制化”功能反而没有很好的体验，沦为彻彻底底的四不像。 后来，项目黄了。再后来，我们花了很多精力，把定制化的那些功能解藕，抛弃，重新坚持走通用能力的路线。 再再再后来的2017年，我们没等来低代码的春天，把团队解散掉，公司结业掉了。截止目前为止，任然有小几十个客户项目在使用我们的平台，尽管已经超过四年没有功能迭代。尽管包括我在内的团队人员已经天各一方。 王婆卖瓜一下我们当初做出来的东西，底座包括了一套傻瓜化能过在线建标做ddl的“动态数据库表”引擎，包括了一套bpmn标准的，可视化拖拽的工作流引擎（内置了activiti），包括了可以在界面做ux和自定义表单的“视图”管理模块，包括了一套支持groove和el脚本语言的执行引擎，包括了开放api，可以引入标准化的外部数据源，包括了企业微信的配置化绑定和对接。 非广告。有感而发，仅缅怀一下已逝去的一段青春。
2022-03-23 - 赵鑫 👍（1） 💬（1）
MVP：最小价值产品或最小可视化产品，这在精益创业是中很重要的概念。也就是先臆想一款产品，他有什么功能，要解决用户什么需求。但是，没有经过用户验证的功能是很危险的！！！所以在开发运营之前，先去验证该产品要解决的用户需求确实是存在的。 这个是我在知乎搜到的答案，请问此处的MVP阶段是否是这个含义
2022-03-25 - Hello,Tomrrow 👍（0） 💬（1）
成熟期，优先发展低代码平台的通用能力，非常赞同这个观点。 不管是对低代码公司的老板、投资人，还是购买低代码平台的客户，最优先关注的肯定是收益。产生收益的是业务能力，这是一个公司保持竞争力的直观体现。 技术能力是支撑业务能力实现的一种手段，不是唯一手段。只有技术能力不断积累了，对业务的支撑才有更大的想象空间。卡脖子的问题不解决，就会受制于人。低代码平台的通用能力就是其“卡脖子”的问题，不提升这个能力，最后这个平台只会在一片谩骂嫌弃声中消失。 这对以低代码平台为卖点的创业公司是“性命攸关”的问题。
2022-04-01 - freeman 👍（0） 💬（1）
请问有交流群么？
2022-03-21 - sheeeeep 👍（0） 💬（1）
请问老师内秉性知识是什么意思？搜了一下没有看到相关结果
2022-03-21 - yalda 👍（5） 💬（1）
去年搞过一个简单的低代码项目（当时是两个人），开创性地基于 TypeScript define type + reflect-meta 替代了 JSON Schema 的协议方案。但是使用场景非常狭窄（只解决了小程序首页） 今年换了领导；要我们对着钉钉宜搭 & 简道云抄，两个月上线（4个人）；诶。。。
2022-05-05 - 黑丝键盘 👍（1） 💬（0）
讲的不错，就是有点啰嗦，希望以后能精简一些。
2022-06-09 - Geek_12e8fd 👍（0） 💬（0）
除了Dashboard场景和表单场景，低代码技术还与许多其他场景“天作之合”。以下是一些常见的场景，以及低代码技术如何与它们结合，并对现有业务产生积极效果： 场景一：企业内部管理系统 特点：企业内部管理系统是企业日常运营的重要组成部分，但传统系统开发需要大量时间和人力成本。场景二：移动应用程序开发 特点：移动应用程序开发需要考虑不同移动设备和操作系统的适配性，传统开发方式较为复杂。场景三：电子商务平台开发 特点：电子商务平台需要考虑用户交互体验、数据库管理、支付系统等多个方面的需求。场景四：业务流程管理（BPM） 特点：BPM关注当前情况并提出改进方法，使组织更加高效、有效和富有成效。场景五：商业智能与分析 特点：商业智能（BI）结合了数据可视化、预测分析等功能，帮助企业做出数据驱动的决策。场景六：定制化应用开发 特点：企业有时需要开发特定的应用程序来满足其独特的需求。总的来说，低代码技术与各种业务场景的结合能够为企业带来显著的效果。通过提高开发效率、降低开发成本、优化业务流程和提高用户体验等方式，低代码技术为企业的数字化转型和业务发展提供了强有力的支持。
2024-06-14 - Geek_12e8fd 👍（0） 💬（0）
为了满足构筑低代码编辑器的开发能力，组件集需要具备以下功能特征和非功能特征： 功能特征： 模块化：组件集应提供模块化设计，使得不同的功能单元可以独立开发、测试和部署。每个组件应该具有清晰定义的接口和依赖关系，以便于集成和复用[1][4]。 可视化编辑：组件集应支持可视化编辑，允许用户通过拖拽、配置等方式快速构建应用程序。这包括界面元素的布局、控件的添加与配置、业务逻辑的编排等[1][2][3]。 数据绑定：组件集应提供数据绑定功能，使得界面元素可以动态显示和更新数据。这包括与后端数据源（如数据库、API等）的集成，以及数据验证和转换等[1]。 事件处理：组件集应支持事件处理机制，允许用户定义组件之间的交互逻辑。这包括用户交互事件（如点击、拖拽等）、系统事件（如数据更新、网络变化等）等[1]。 自定义UI：组件集应提供自定义UI的能力，允许用户根据需要调整组件的外观和行为。这包括主题样式、菜单样式、控件属性等的自定义[1]。 权限管理：对于需要权限控制的应用场景，组件集应提供权限管理功能，支持用户角色的定义、访问控制等[1]。 非功能特征： 可重用性：组件集应强调组件的可重用性，确保同一组件可以在不同的应用程序中重复使用，降低开发成本和维护难度[4]。 扩展性：组件集应具备良好的扩展性，允许用户根据需求添加自定义组件或修改现有组件的功能。这包括提供API接口、插件机制等[2][3]。 兼容性：组件集应具有良好的兼容性，能够支持不同的操作系统、浏览器和设备。这有助于确保应用程序在各种环境下的稳定性和一致性[2]。 性能优化：组件集应关注性能优化，确保在构建复杂应用程序时能够保持良好的运行效率和响应速度。这包括优化组件的渲染性能、减少不必要的计算和内存占用等[2]。 易用性：组件集应易于学习和使用，提供清晰的文档、示例和教程等支持材料。这有助于降低学习门槛和提高开发效率[3]。 安全性：组件集应关注安全性问题，确保在构建应用程序时能够遵循最佳的安全实践。这包括输入验证、防止跨站脚本攻击（XSS）、防止跨站请求伪造（CSRF）等[3]。 综上所述，为了满足构筑低代码编辑器的开发能力，组件集需要具备一系列功能特征和非功能特征。这些特征共同构成了低代码平台的核心竞争力，有助于提升开发效率、降低开发成本并加速应用程序的交付。
2024-06-14 - Geek_7e0d86 👍（0） 💬（0）
低代码平台，需要时间成本，这对于大部分公司来说可能都是一个巨大的问题。18年以来先后接触过两个低代码平台的开发，都不疾而终，公司最多给你两个月时间。
2023-05-17 - ifelse 👍（0） 💬（0）
打卡
2023-02-16 - Andrew陈海越 👍（0） 💬（0）
受资源限制，LCDP的实现需要采用逐步迭代的思路。优先满足通用能力，在紧急情况下定制需求。跟客户的关系，抗压能力都影响
2023-01-03 - softbaddog 👍（0） 💬（0）
一看就是作者的经验之谈，循序渐进，逐步迭代的思路非常有必要。但是资源和时间都是有限的，如果在有限的资源下活下来，要取舍的东西很多，大公司可能还养得起，小公司是不是应该更加聚焦某个点更适合发展呢？把大量资源投入到通用化能力上，但又做不到100%，会不会得了芝麻丢西瓜呢？
2022-11-19 - Johnney 👍（0） 💬（0）
我感觉saas系统其实也是一直低代码，通过开发一套通用性强的多租户系统，可以满足大多数租户的需求，即使有些定制化需求满足不了，我们也可以使用兜底策略。
2022-06-06 - WangBo 👍（0） 💬（0）
总结下来： 1、坚持核心架构设计不能被动摇：核心架构模型是地基，一旦被破坏，短期有收益，长远看得不偿失，后期需要非常大的资源甚至架构变更来适应兼容。 2、业务需求转化为通用扩展功能：业务需求的背后其实是通用能力的缺失，可以把业务需求转化为通用能力（当然不好转），可以通过先提供兜底策略（用起来不那么方便、需要业务方更多的code来解决业务问题，甚至前期是平台的研发人员手工先支持），再通过迭代的方式来不断补充完善通用能力。 3、要落地前两点，和业务同学的关系以及获得业务的信任支持非常重要。放低姿态、多回访、同步更细致的交付信息（比如不是不做不支持，而是慢慢支持，以达到更好效果）。
2022-04-10