为什么很多程序员讨厌低代码？（为什么很多程序员讨厌低代码的人）

你是一位木匠，心灵手巧，还能自己设计出符合不同需求的榫头，搭起房子来又快又好。一层楼，两层楼轻轻松松搭好就能住人了，你老板对你很满意。但是慢慢的发现地价越来越贵，如果只搭一两层楼不划算，需要搭个七八层楼的房子，这个时候你可能就犯难了。地基需要打多深？材料需要刚度和弹性需要怎样的，什么样的结构搭出的房子不容易倒，还防地震？另外老板喜欢大平层，不喜欢房子里面有这么多柱子，怎样的设计出大跨度，又承重的梁？

随着外部环境的变化，地价越来越高，大家对房子的需求越来越复杂，原来多快好省的房子不能满足要求了，也没办法扩展了，还是要推到重来。

于是你，重新拿起书，学习数学几何物理等等基础学科，然后在学习建筑学，了解应力结构，了解不同材料之间的区别，学习不同建筑结构之间的差异。学会在图纸上画好，计算好，再找施工队来施工。现在你搭房子可能没有这么快，但是你搭出的房子各项参数很明确，能支撑多高的建筑，能防多少地震，如果减少柱子，留下的扩展空间是多少？随着企业的成长，你的房子也可以慢慢的逐步改造满足需求。

低代码的优势就是快！但是他诱导你从表面思考问题，拖拖拉拉一个满足任务的界面就出来了。也是这样快，你越是以快速解决表面问题为荣，A部门的需求拖拉一个应用，B部门的需求拖拉一个应用，慢慢的你的公司都是这种快速应用，你没有时间也没有兴趣去调研，为什么会有这个需求，A B部门的需求有没有关联性，他们的数据如果保持一致？这样的一堆低代码应用表面很华丽，一年后，你可能连应付审计的能力都没有，两年后当你要数字化转型的时候，没有应用的数据含义，对应关系也理不清楚。为什么，就是低代码的设计就是解决眼前任务为核心的设计理念造成的。它不建议你数据建模，都是从表及里的开发的。

真正的好的系统，不在于界面。它的价值在于对业务的理解，业务的模型化，对领域模型的设计整理。 是由下而上的，先分析你的业务，再对业务建立模型，同时对你的业务梳理，反过来告诉你如果做数字化，根据模型的分析反过来和你讨论你的流程是不是需要重构！并不是简单的做系统，不是简单的根据一线的业务员完成任务的角度来做系统！而是各个角色的综合需求，业务数字化的需求来设计系统，帮助企业用数字来表达业务。

这也是为什么很多公司上一套软件系统的同时需要业务咨询的原因。

程序员不讨厌低代码。简单的工具流程化的东西可以暂时用低代码平台来实现： Excel VBA其实就已经是一个很好的低代码平台了。

程序员是认为很多重要的工作低代码平台完成不了