在今天的文章中，我们将回顾出版于1972年的《表达与意义(Representation and Meaning)》，其中囊括了由1960年到1965年之间发表的多篇论文。
首先是书中2.2章节内提到的由Herbert A. Simon撰写的《启发式编译器(The Heuristic Compiler)》一文：
二者的一大区别在于，我们将相对简单的任务称为“编码”，而将比较广泛且更为艰巨的任务称为“编程”——其可能包含选择或者设计一种适当的问题表达方式，而前者则不涉及这一点。
这不禁让我想到了与测试、检查与自动化相关的讨论——特别是以下几个问题：
- 我们无法实现自动化测试，但可实现自动化检查。
- 我们为何不讨论编程自动化?
我们无法实现自动化测试; 但可实现自动化检查
关于编码与编程的表达则存在着类似于检查与测试间的关系理解。
- 编程与测试：
在广泛性与难度上高于编码与检查。
涉及对适当问题加以表达的选择与设计。
- 编码与检查:一种对编程或测试内已完成工作的表达。
我们为何不讨论编程自动化?
之所以不讨论编程自动化，是因为我们能够进行自动编码，具体包括：
- 代码自动补全。
- 宏系统。
- 自动生成代码注释，即projectlombok。
- 翻译/编译器。
在涉及编码时，我们往往总会想到如何以自动化方式加以实现。而且自存在编码这一概念时，我们就已经开始采用自动化机制。
我个人从业以来参与的第一个项目就是利用JSP图生成程序代码。在该项目中，我会利用自动方式生成C与COBOL代码。
Herbert A. Simon在这篇论文中将编程任务的自动化执行视为一种问题解决实践。而编码自动化则已经成为一种给定且理所当然的前提。
图表
我在自己的读书笔记中绘制了这样一份图表：
并在图表中添加了以下附注信息：
- “…”代表开发并不只包含编程与测试这一事实。
- 编程与测试皆拥有自己的多个表达层——其中一些可以轻松实现自动化处理，另一些则必须人为介入(难以实现自动化)。
- 我们会对其中的“简单”层进行自动化。
为了让大家看得更清楚，这里我整理出了更为清晰的图表版本：
- “-”代表每一项所谓“高级任务集”都拥有与之对应的、易于实现自动化的低级层(可能具备或不具备对应名称)。
- 我在检查表达当中添加了“断言”一项，因为我们会对if(x==2){return false;}这类特定条件进行检查，并在报告与监控内容中添加相关检查结果。我们利用这种断言中止自动化流程的执行。
总结
我尝试开发一套自动化模型以作为软件开发流程中的组成部分。这意味着我希望尽量避免被束缚在测试自动化乃至自动化这一概念本身，而应将其视为更为广泛的开发流程内工具支持机制(而非局限于测试或者测试人员群体之内)。
我认为这种方式能够让人们更轻松地通过沟通确定程序员这一职能角色，因为我们不再讨论自动化测试这一议题——我们实际讨论的是如何对开发方法中的常规自动化流程加以延伸，具体包括：
- 在应用程序内执行代码流。
- 检查结果。
- 断言这些检查结果。
这就是我通过计算科学的历史文献中发现的宝贵价值。也希望大家能在闲暇之时翻翻故纸堆，没准会找到一些意外的惊喜。标题
原文标题：Relating Programming, Testing, Coding, and Checking 作者：Alan Richardson
