【.com快言】虽然计算机技术一直在快速发展，但许多与时代相关的书籍和论文仍然包含丰富的有价值的指导信息。编程包括一个易于自动化的层，称为编码——就像从测试到检查。而测试和编程本身比开发的宏观概念更人性化。在今天的文章中，我们将回顾1972年发表的《表达与意义(Representation and Meaning)》，其中包括1960年至1965年间发表的几篇论文。首先是HerbertA.Simon的文章《启发式编译器(The Heuristic Compiler)》，在本书的2.2章中提到：abigdifferencebetweenthebigdifferencebetween二是我们将相对简单的任务称为“编码”，而我们将更广泛、更困难的任务称为“编程”——这可能涉及选择或设计适当的问题表达，而前者不涉及这一点。这让我想到了与测试、检查和自动化相关的讨论——特别是以下问题：我们不能使测试自动化，但我们可以使检查自动化。为什么我们不讨论编程自动化？我们不能自动化测试；但我们可以自动化检查。编码和编程之间的关系类似于检查和测试之间的关系。编程和测试：广度和难度高于编码和检查。涉及选择和设计适当的问题公式。编码与检查：在编程或测试中完成的工作的表达。为什么我们不讨论编程自动化？我们之所以不谈编程自动化，是因为我们可以做自动编码，具体来说：代码补全。宏系统。自动生成代码注释，projectlombok。翻译器/编译器。当谈到编码时，我们倾向于考虑如何将其自动化。由于编码的概念已经存在，我们已经接受了自动化。个人实践以来参与的第一个项目是使用JSP图生成程序代码。在这个项目中，我将使用自动方式生成C和COBOL代码。在本文中，HerbertA.Simon将编程任务的自动化视为一种解决问题的实践。另一方面，编码自动化已成为理所当然的事情。Diagram我在读书笔记中画了这样一张图：并在图中添加了如下注释信息：“...”表示开发不仅仅包括编程和测试。编程和测试都有自己的表达层——其中一些可以很容易地自动化，而另一些则需要人工干预（难以自动化）。我们将自动化这个“简单”层。为了让大家更清楚，这里我整理了一个更清晰版的图：“-”表示每一个所谓的“高层任务集”都有一个对应的底层，很容易自动化（可能有或没有相应的名称）。我在检查表达式中添加了一个“断言”项，因为我们会检查具体条件如if(x==2){returnfalse;}，并在报告和监控内容中添加相关的检查结果。我们使用此断言来中止自动化流程的执行。总结我试图开发一个自动化模型作为软件开发过程的一个组成部分。这意味着我想尽量避免被测试自动化甚至自动化本身的概念所束缚，而是作为更广泛的开发过程中的一种工具支持机制（不限于测试或测试人员群体）。我认为这种方式更容易让人们交流和识别程序员的功能角色，因为我们不再谈论自动化测试——我们实际上是在谈论如何在开发方法中扩展正常的自动化过程，这些包括：执行应用程序中的代码流。测试结果。断言这些检查的结果。这是我在计算科学的历史文献中发现的有价值的东西。也希望大家在闲暇之余翻翻那堆旧论文，说不定会发现一些意想不到的惊喜。标题原标题：RelatingProgramming,Testing,Coding,andChecking作者：AlanRichardson
