【51CTO.com快譯】盡管計算機技術一直在快速演進，但不少年代久遠的相關書籍與論文仍然包含大量寶貴的指導性信息。編程當中包含一個易于自動化的層，被稱為編碼——其類似于測試之于檢查。而測試與編程本身又人性于開發這一宏觀概念。

在今天的文章中，我們將回顧出版于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

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】