可能大家谈到低代码想到更多的是低代码搭建页面的平台，内部不少也是此种，其实对于偏逻辑编排、服务 BaaS 能力的偏可视化方式其实也算低代码，旨在「通过少写代码，用更便捷的方式来实现原本需写代码的工作」。 说到低代码，喜欢的人特别喜欢，不喜欢的人很不喜欢，此外也有“假装”去喜欢的，也有喜欢得不明不白的，我现在对于低代码是有点儿喜欢的那种，不过只限于「在特定领域，实现需求的速度比熟练工程师写代码要快的场景」，这种场景下用起来真心会比较爽，可能也用得不爽的时候，但是这种不爽远小于他带来的效益减去原本敲代码的投入，也很值得将这类产品做到好用爱用。 其实低代码产品是比较难做成的，特别是大而全的那种，由于考虑因素过多，导致步调很慢，也很难做到很易用，导致一边投入很大，一边又急切上线落地使用，从而出现平台方觉得投入很苦，使用方觉得不太好用还需吃狗粮的矛盾，往往需经过忍耐很长时间才可「守得云开见月明」，不过很多都在没有见月明的时候就奄奄一息了。反而专门领域的比如说表单、表格、图表低代码搭建活的很不错。还有一些 BaaS 类单领域的活得也还可以，我个人更偏向「易用的可很轻快解决对应领域问题低代码产品
近几年，低代码技术发展的如火如荼，在商业领域也是目前市场关注的重点.作为商业低代码产品通常是用来助力企业信息化转型的利器，其中的核心逻辑是通过将软件开发普民化，让传统企业中更熟悉企业运作流程的业务人员可以亲自动手开发适合自己业务的系统或平台。这个领域内在市场上已经有国内外很多有竞争力的产品，钉钉宜搭作为阿里巴巴的商业低代码产品也是其中的一员。 今天重点讲的是另外一个领域，低代码技术在产研团队应用落地的相关话题。商业低代码产品可以赋能业务团队具备研发能力，但对于已经具备不错研发能力的互联网厂商的产研团队来说，商业低代码产品可以解决很大长尾应用场景的快速开发，但对于产研团队的服务的主要业务上，并不是完全适用。对于阿里巴巴来说，集团里各BU因地制宜建设了众多适合本业务的低代码平台/产品，其实也都是用于解决通用型商业低代码产品不适用部分的问题。
1.地图数据作业平台由大型的WebGIS"综合作业"逐步转换为人机结合，所见即所得的流水化"简单作业"; 2.流水化作业的特点是单一车间交互简单，但每个车间都有定制的业务逻辑（难以配置化实现，适合有扩展能力的低代码方式）； 3.作业平台低代码建设过程中，即使是任何一个简单作业车间也存在数据校验，组件联动，保存结果转换等逻辑（下图标牌场景车间为例）； 4.作业平台低代码的建设目标是让产品，工艺等非研发同学能独立搭建车间，因而要尽可能将逻辑操作可视化，少写或不写逻辑代码； 5.非前端研发同学并不能很好的理解一些前端的基本概念：例如事件驱动，数据不可变 immutable原则， 数据双向绑定，组件（非）受控等；
