上一篇文章IOT-Tree 1.7.0实现了一个类似Node-Red的流程功能中，我提到了如下文字内容：

通过这样的图形化编程机制把软件开发直接分成了两个层次。

1. 一个是应用层面，给用户、项目实施技术人员或维护人员能够在不需要掌握深入技术的前提下，还可以快速实现业务需要，并且极大的降低后续业务微调成本。毕竟灵活的图形化流程能够在线修改和调整。

2. 二是在节点开发上，则需要一定技术能力的程序员来完成，但开发方式上就好比制造有一定技术规范的零件，零件功能通过流程节点的封装，屏蔽了复杂的底层知识。

这个也是我做软件框架时经常想的一个问题。仔细研读了自己写的这段文字，发现自己还有不少想法。

1，这好像就是我们这个世界的技术规律

无论新出的技术一开始看着那么高精尖，只要在人类生产过程中，逐步推广应用到日常生活工作，那么都会变的很普通。那些复杂的技术都会被封装到黑盒子中。网上看到有个老奶奶给无人机加电池和放种子，熟练程度看着这个很高级的无人机和过去骑的自行车没多大区别。

我们软件也应该是这样，各种框架把我们从底层需要关心的细节不断封装沉淀，最终带动整个行业的发展。但同时，绝大多数程序员都变成了那个老奶奶了——这同时也是个悲剧。

无人机内部的芯片，飞控这些才是真正有技术含量的东西，掌握了这些技术的公司那就挣钱很爽了。而那些使用无人机帮人施肥的人，都成为了这个产业链的下游。从这个角度，我们是不是也应该掌握框架的底层呢？

难：软件太容易复制了，因此绝大多数程序员的“卷”是必然的结果。

2，程序员如何找出路呢

其实也不用太悲观，能掌握底层并占有市场的毕竟还是少数。业务层面的软件需要就像传统行业一样，总是有需求的。嗯，我认为IT现在也基本是传统行业了，现在IT圈这个炸那个炸也应该是程序员没有以前那么吃香了，然后造成了心理的不平衡。

出路肯定有，我感觉大致有如下

1） 深耕某个行业 2）在一个很服务很多用户的平台出力 3）找风口机会——这个失败概率比较大

4）转行——带着自己的IT技术，应该比一般人好混 5）其他（自己想吧）

3，还是讲讲技术吧——消息流程

Node-Red和IOT-Tree的消息流程和一般的流程不一样。因为里面跑的都是消息包。从其实节点（触发节点）产生消息，随着节点和路径流动。某种意义上是一种结构清晰和简单的一种流程。唯一稍微需要注意的是上下文：节点上下文和流程上下文。这个本质就是节点自身的变量和流程自身的变量，他们的作用域不一样而已。

不过，我研究了一下控制流程实现，发现确实有不少优势：

1）节点本身就是状态，只要分配好控制状态机的状态在不同的节点上，后续控制逻辑设计就会变得很简单。

2）更能适应自控、物联网系统数据的特点。自控系统和物联网数据标签和我们程序定义的变量不同，除了正常的取值，还需要考虑不正常的情况——如网络中断造成的无效值。而是要消息流里面的标签，则只需要做个简单勾选就可以决定输出的消息是否应该走正常流程或异常流程。这个如果用代码实现，就会显得比较乱。

3）使用此技术对传统的软件企业很有用。这个流程天然会让企业的业务技术进行积累——节点积累，并且可以大大减少系统之间的耦合。积累和解耦——可以大大降低软件企业的成本。

先这些，想的有点乱，不过都是干货哦！！