吐槽一下，欢迎拍砖
18 回复1136 浏览
随着明道云产品的不断升级，尤其是自定义插件开放以后，我越来越有一种担心，就是像我这种没能力搞代码开发的，更不可能去学会自定义插件了。往后的日子可怎么过？？？
一些功能需求如果是目前明道零代码实现不了的，官方会不会直接推给二开、自定义插件？这貌似看起来挺合理：明道是开放的，支持用户的深度定制。这种方式看似明道也会轻松了许多，很多需求和建议可以通过上述方式来解决，而不是排期排资源，通过明道自身来完善。
但这会不会带来一个问题，让明道可能会偏离初衷？让一些忠实的“零代码”粉丝只能望洋兴叹？
很多明道的最终用户以及伙伴，我们统称为用户，他们在明道没有推出自定义插件之前就选择了明道，我想选择的原因可能很大部分是因为“零代码”能力、易学、易上手、业务人员真的能掌握起来，而且功能的确很完善和强大。这些特性或者称之为优势，是明道云区别于其他低代码平台的核心。很多用户是冲着这个来的，但如果明道发展的越来越“技术化”，这和市面上普遍的“技术型”低代码平台相比，又有什么差异化呢？
自定义插件、二开，对于有技术能力的用户的确是一件非常好的事情，然而不断推出丰富的具备零代码能力的组件，不正是一个零代码平台应该夜以继日所做的事情吗？
但愿我的担心是多余的，希望明道在零代码能力上继续深化，一直成为业界顶流。
作为用户，可以尽量绕开不用，但是对于明道云这种托底的能力是必须的，不然一个项目一旦做深了就做不下去了、或者压根不敢往深了做，岂不是笑话
受教了，还是要有自己的技术能力，不能万事依赖零代码 👍
你做不到 100% 的零代码的，典型的就是求最优解，这种算法，首先需要很深的数学能力和算法能力，还需要花时间去研究，即使实现了，还需要去优化，寻找更大的最优解
这就是明显的垂直领域，你一个业务人员即使有这个能力，也没这个时间，所谓的各司其职。即使有 gpt 帮你生成，你没有专业的知识也无法识别质量如何。
本来个性化的东西，就得搞二开去实现，毕竟各行各业，甚至同业不同公司，以及不同需求对于业务要求也不一样，更别说数据展示了。不可能有一款开放性软件可以 100% 契合任意一家企业的业务。
但是你往大了想，哪一家公司的产品不是想降低产品的边际效益？但是实际上是做不到 100% 的需求覆盖的，也不可能做得到。更何况做技术和做业务本身就是两个思维层次
任何一个公司，就好比你自己的企业，你买了别人的产品，在售后上的着急程度肯定体验过，你就没想过自己掌握特定的技术，秉着【万事再也不求人】想法，对吧。
换位思考，插件就是这么一个契机和优势，让你能做到差异化，对于你企业的竞争力是个提升，而不是担心
嗯嗯，说的好，所以需要明道团队不断的组件化更多的功能出来。先代码解决问题，后抽象转化为零代码能力。这要看他们的持续迭代已经对需求的消化吸收
客户关于零代码的需求越来越多，很多需求如果想依靠明道云通过组件的方式提供出来可能需求花费不少的时间，我觉得目前提供的代码块也好，插件也好，只是一种权宜之计，让传统的开发人员能够介入进来，与业务人员一起快速实现功能，快速交付。然后随着时间的推移，这些需要代码块才能实现的功能，需要插件才能实现的功能慢慢的会不断的组件化，这是我对于当前低代码趋势的一种看法
我们是八排
实际上，现在的明道云后端能力基本是满足要求的，核心是里面有代码块可以处理复杂逻辑
前端支持各种表单事件各种插件后，依然只是类似的理念，只是提供了更丰富的扩展能力
是否需要代码块完全是基于业务场景考虑的
同意，三排可以形成稳定战斗能力。
随着业务拓展还是要不断的分工。
零代码那是理想状态，一些复杂的业务场景还是需要代码支持的，所以各自分工，如何灵活运用 HAP 进行项目交付，客户满意，又能成本控制，这个才是王道，灵活的变现。
总结客户需求，哈哈哈 😄
嗯嗯，这正是我想表达的，你总结的非常好，三言两语切中要害 👍
明道云定位就是零代码快速搭建应用，前端写代码的功能，这个我觉得只能是权宜之计，最终还是得回归到零代码搭积木，不然的话就和定位不符。客户就是冲着所见所得，现场开发买的，如果弄出大量写代码的东西，那就本末倒置了。写代码确实能带来扩展性，但我觉得零代码才是核心，真正体现技术和优势的东西，不然和友商很难拉开插件，又搞成同质化竞争。
感谢任老板亲自回复，没有最好，只有更好，相信大家跟着明道都会越来越好 🚀️
😄 任总都说了有了分工才有效率，像你们这些有开发能力的大拿必须参与进来啊，这样才能丰富插件市场。
放心，吾等廉价的劳动力不会去开发插件的
大胆怼老板：you can you up!
这个我觉得您不需要担心。我始终相信，对于 HAP 上的应用实现，业务知识至少要占据一半的价值。这部分是和代码开发毫无关系的。HAP 伙伴中，至少有 1/3 是行业和咨询出身，他们证明价值绝对不是依靠插件开发能力。相反，即便能够写汇编语言，没有业务知识，依然无法给客户带来价值。
从另外一个角度，我们觉得 HAP 的生态应该有多元性。我们主要依靠有垂直经验的 ISV，但也需要开发者通过技术能力来参与。有了分工，才有效率。