大牛讲课，面面俱到

原以为Git只能管理源代码版本的工具，没想到还可以有这种用法，做为其他软件的后台核心组件。

去年搞过一个简单的低代码项目（当时是两个人），开创性地基于 TypeScript define type + reflect-meta 替代了 JSON Schema 的协议方案。但是使用场景非常狭窄（只解决了小程序首页） 今年换了领导；要我们对着钉钉宜搭 & 简道云抄，两个月上线（4个人）；诶。。。

受益匪浅。。。感谢 1. 为编辑器使用组件提供了协议标准，并对生成器与编辑器进行了解耦 2. 为后续业务组件的接入提供了协议通道，充分体现了协议标准的优越性 后期可以动态加载业务组件。间接解决了平台核心层和业务方的耦合

感谢老师的分享，及时雨，让我了解低代码平台的全貌，为日后工作中做低代码平台的方向和规划起到了非常重要的参考作用

印象最深的莫过于跑了N年的angular4，要升级到angular8，连依赖包都不支持了，当初也没有一点点随着angular版本更新而更新，以至于最后只能将就用，要再改也是重新开发一套了。 还有就是element plus的版本更新，导致某些样式效果失效，没办法只能手工改一波。 处理器的确是很好的想法，不过处理器的开发和维护需要长期有人坚持，否则一旦放个几年，就是毁灭性打击，尤其是大版本更新。

受益匪浅，感觉思路打开了，老师讲的是核心思想，关键是理解这个思想。这个对成天写业务代码的我来说帮助很大。

总结得真好。 我13年创业想打造的产品，当时想做的最终形态就是作者上一节描述的那个天花板模型。作者说的每一点都打到我心里。 这一节描述的通用性和业务定制化也是我们当初矛盾过的两难问题，当时mvp阶段，不知道到底是运气好还是运气不好，拿下了一个百万级的客户项目。甲方it负责人由于认可低代码理念（当时是2013年，我们都不知道自己做的东西叫做low code），给了我们充分的耐心。但再多的耐心始终敌不过需求部门的压力。由于我们担心自己变成“毒瘤”，担心项目黄了，担心现金流断了（当时拿了预付款之后立即做了人员扩招），最终妥协了，放弃一开始定下的通用化策略，投入许多人力做定制化。 慢慢的，产品被带偏了，我们花了许多人力去满足业务需求，但由于mvp阶段底座的不不牢固，以及核心开发人员的分心参与，我们做出来的“定制化”功能反而没有很好的体验，沦为彻彻底底的四不像。 后来，项目黄了。再后来，我们花了很多精力，把定制化的那些功能解藕，抛弃，重新坚持走通用能力的路线。 再再再后来的2017年，我们没等来低代码的春天，把团队解散掉，公司结业掉了。截止目前为止，任然有小几十个客户项目在使用我们的平台，尽管已经超过四年没有功能迭代。尽管包括我在内的团队人员已经天各一方。 王婆卖瓜一下我们当初做出来的东西，底座包括了一套傻瓜化能过在线建标做ddl的“动态数据库表”引擎，包括了一套bpmn标准的，可视化拖拽的工作流引擎（内置了activiti），包括了可以在界面做ux和自定义表单的“视图”管理模块，包括了一套支持groove和el脚本语言的执行引擎，包括了开放api，可以引入标准化的外部数据源，包括了企业微信的配置化绑定和对接。 非广告。有感而发，仅缅怀一下已逝去的一段青春。

确实，真正了解完低代码才能做出理智的判断，是银弹还是毒瘤，品一品就知道了