8最近，在RPA圈子中广为流传一篇关于RPA产品编码风格对比的文章（https://www.rpaplus.cn/2019/1303/），总体是分成代码流派，流程图流派和序列流派这几种类型，以及每个流派的典型产品代表。文章中多少流露出对所谓“代码流派”的不解，作者的解读是更适合开发人员，“对于非开发人员看这个，觉得像看天书，这和敲代码有差别吗？”
粗略看来，作者并没有真的全部用过这几个产品，只是凭着一些产品界面的截图的就妄做了评论。因为这样是最容易的。就好像你见到一个陌生人，最简单的方式就是单纯从外表来评价他。是个胖子，一定是好吃懒做，是个瘦子，就是营养不良。
不过，软件工具的关键是看真正的使用情况和使用效果，并不是只看看外表就算了事的。
首先，有些基础的道理我们要明白，比如什么是形和意。也就是之前软件行业经常谈到的MVC结构，模型-视图-控制器。所以我们看到的RPA软件的编辑界面只是代表了视图的部分，真正起决定作用的是控制器和模型。视图可以有多种多样，可以一行行，可以是流程图，可以是自然语言，可以是图形界面，一种工具也可以同时展示出多种界面视图形态。例如在HTML的编辑界面里就可以看到不同风格的展示形态。而RPA软件真正的核心价值是能否铺捉到你需要控件，能否将需要的操作落在准确的位置上。所以视图和RPA自身的软件能力并没有多大关系，而只和用户的操作喜好以及应用场景有关。
比如图形界面的东西，更容易得到管理者的喜欢，因为管理者并不会去自己动手做开发，而只是远远在旁边看着，图形化的东西看起来更美观。而RPA工具是给自动化编辑者使用的，他们的喜好才会决定产品的走向，不一定是图形化这种看似美好的东西。比如流程图在表达RPA逻辑是最大的问题是需要层层嵌套，在调试一个流程时，早已经把开发者绕晕，不知道自己的代码走到了哪里。所以传统用流程图表达更多提供给管理者使用的视图，是更高维度的流程，例如传统的workflow工作流引擎工具，提供的是不同角色直接的串接，如贷款的审批流程，这些流程很多时候，是用来对上级汇报的。而RPA的应用领域和传统工作流开发是有区别的，需要定义的是细节流程，其实就是员工操作的每个步骤，这些非常细节的内容，管理者通常并不会关注，只有操作者自身明白就好，谁会自己给自己讲流程还要画个流程图，难道以后还要天天拿出来自己欣赏和点评一番。
所以，当大家谈到流程表述时，默认就会认为有图有框有线的就会好，这是个理解误区。其实首先要看你表达的是什么层级的流程，这些流程的使用对象再来谈论这个问题。通常流程的层级可以分为 第一级是业务领域；第二级是业务单元；第三级是活动（按目标的）；第四级是任务（按角色的）；第五级是步骤，由于过于复杂，通常在第五级已经不再使用流程图表达了，而RPA的流程是比第五级还细节的表述。人云亦云本身就是危险的。由于RPA开创的一个前人做流程未能企及的细度和深度，所以大家不能理所应当的认为有图就是好的。
也许这时你会说，虽然有图不一定好，可是用代码一行行的写，一定是不好的。因为开发者要懂专业的编程语言和语法，里面的各种表达式必须要专业人员才能看懂，一行行的写进去费时费力也不好阅读。
我们以Automation Anywhere为例，看看是如何既利用代码行的优势，又巧妙的避开了上面这些缺点的。
专业编程语言?不需要，可以用自然语言来表达，例如下图。文中第一行表达的是启动一个网页；第二行是打开一个Excel文档；第三行是从目录复制一个文件，仔细读下来，其实都是用自然语言的表达。只不过它是用英语来表达的，对平时习惯汉语的我们有点小小障碍。
专业表达式?不需要，可以随意定义变量，而不用知道变量类型，例如下图，AA的变量只有三种，开发者不用纠结什么变量类型和表达式之类的约束，这就是对普通用户的最大简化。另外，变量的使用时，也不用关心类型。
一行行的代码编写?不需要，一行内容只需要一拖一拽，配置一下就可以完成，看似一行一行的，里面没有一行是需要用手敲键盘输入进去的。同时，用最简练的自然语言表达了复杂内在逻辑，对开发者是最容易阅读的，不需要流程嵌套那样一层层点进去才能看到处理逻辑。例如下图，需要处理文件夹中的每个文件，只需要在这里Loop命令里配置以下就好了。
什么叫做细思极恐，就是这个道理，一家做了十几年自动化的软件公司，所有的使用场景和操作细节都来自于真实用户和真实应用场景的不断积累，而不是来自初学者和旁观者的眼光。
最后，稍稍剧透一下Automation Anywhere的下一代产品，满足各种使用者，管理者以及各位看官的好奇心。三种视图同时提供，各取所需，而且是全web版，不需要本地安装开发器，随时随地，用Mac也能完成RPA的开发。
