美的程序不可能从修修补补中来。它必须完美的把握住事物的本质,否则就会有许许多多无法修补的特例(转)
2015-04-21 22:40
218 查看
现在的很多公司,包括 Google 和我现在的公司 Coverity,都喜欢一种“测试驱动的开发”(test-driven development)。它的原理是,在写程序的时候同时写上自动化的“单元测试”(unit test)。在代码修改之后,这些测试可以批量的被运行,这样就可以避免不应该出现的错误。
这不是一个坏主意。我在 Kent 的编译器课程上也使用了很多测试。它们在编译器的开发中是不可缺少的。编译器是一种极其精密的程序,微小的改动都可能带来重大的错误。所以编译器的项目一般都含有大量的测试。
然而测试的构建,应该是在程序主体已经成形的情况下才能进行。如果程序属于创造性的设计,主体并未成形,过早的加入测试反而会大幅度的降低开发效率。所以当我给 Google 开发 Python 静态分析的时候,我几乎没有使用任何测试。虽然组里的成员催我写测试,但是我却知道那只会降低我的开发效率,因为这个程序在几个星期的过程中,被我推翻重来了好几次。要是我一开头就写上测试,这些测试就会碍手碍脚,阻碍我大幅度的修改代码。
测试的另一个副作用是,它让很多人对测试有一种盲目的依赖心理。改了程序之后,把测试跑一遍没出错,就以为自己的代码是正确的。可是测试其实并不能保证代码的正确,即使完全“覆盖”了也是一样。覆盖只是说你的代码被测试碰到过了,可是它在什么条件下碰到的却没法判断。如果实际的条件跟测试时的条件不同,那么实际运行中仍然会出问题。测试的条件往往是“组合爆炸”的数量级,所以你不可能测试所有的情况。唯一能可靠的方法是使用严密的“逻辑推理”,证明它的正确。
当然我并不是让你用 ACL2 或者 Coq 这样的定理证明软件。虽然它们的逻辑非常严密,但是用它们来证明复杂的软件系统,需要顶尖的程序员和大量的时间。即使如此,由于理论的限制,程序的正确性有可能根本无法证明。所以我这里说的“逻辑推理”,只是局部的,人力的,基本的逻辑推理。
很多人写程序只是凭现象来判断,而不能精密的分析程序的逻辑,所以他们修改程序经常“治标不治本”。如果程序出问题了,他们的办法是看看哪里错了,也不怎么理解,就改一下让它不再出错,最多再把所有测试跑一遍。或者再加上一些新的测试,以保证这个地方下次不再出问题。
这种做法的结果是,程序里出现大量的“特殊情况”和“创可贴”。把一个“虫子”按下去,另一个虫子又冒出来。忙活来忙活去,最后仍然不能让程序满足“所有情况”。其实能够“满足所有情况”的程序,往往比能够“满足特殊情况”的程序简单很多。这是一个很奇怪的事情:能做的事越多,代码量却越少。也许这就叫做程序的“美”,它跟数学的“美”其实是一回事。
美的程序不可能从修修补补中来。它必须完美的把握住事物的本质,否则就会有许许多多无法修补的特例。其实程序员跟画家差不多,画家如果一天到头蹲在家里,肯定什么好东西也画不出来。程序员也一样,蹲在家里面对电脑,其实很难写出什么好的代码。你必须出去观察事物,寻找“灵感”,而不只是写代码。在修改代码的时候,你必须用“心灵之眼”看见代码背后所表达的事物。这也是为什么很多高明的程序员不怎么用调试器(debugger)的原因。他们只是用眼睛看着代码,然后闭上眼,脑海里浮现出其中信息的流动,所以他们经常一动手就能改到正确的地方。
http://kb.cnblogs.com/page/518955/
这不是一个坏主意。我在 Kent 的编译器课程上也使用了很多测试。它们在编译器的开发中是不可缺少的。编译器是一种极其精密的程序,微小的改动都可能带来重大的错误。所以编译器的项目一般都含有大量的测试。
然而测试的构建,应该是在程序主体已经成形的情况下才能进行。如果程序属于创造性的设计,主体并未成形,过早的加入测试反而会大幅度的降低开发效率。所以当我给 Google 开发 Python 静态分析的时候,我几乎没有使用任何测试。虽然组里的成员催我写测试,但是我却知道那只会降低我的开发效率,因为这个程序在几个星期的过程中,被我推翻重来了好几次。要是我一开头就写上测试,这些测试就会碍手碍脚,阻碍我大幅度的修改代码。
测试的另一个副作用是,它让很多人对测试有一种盲目的依赖心理。改了程序之后,把测试跑一遍没出错,就以为自己的代码是正确的。可是测试其实并不能保证代码的正确,即使完全“覆盖”了也是一样。覆盖只是说你的代码被测试碰到过了,可是它在什么条件下碰到的却没法判断。如果实际的条件跟测试时的条件不同,那么实际运行中仍然会出问题。测试的条件往往是“组合爆炸”的数量级,所以你不可能测试所有的情况。唯一能可靠的方法是使用严密的“逻辑推理”,证明它的正确。
当然我并不是让你用 ACL2 或者 Coq 这样的定理证明软件。虽然它们的逻辑非常严密,但是用它们来证明复杂的软件系统,需要顶尖的程序员和大量的时间。即使如此,由于理论的限制,程序的正确性有可能根本无法证明。所以我这里说的“逻辑推理”,只是局部的,人力的,基本的逻辑推理。
很多人写程序只是凭现象来判断,而不能精密的分析程序的逻辑,所以他们修改程序经常“治标不治本”。如果程序出问题了,他们的办法是看看哪里错了,也不怎么理解,就改一下让它不再出错,最多再把所有测试跑一遍。或者再加上一些新的测试,以保证这个地方下次不再出问题。
这种做法的结果是,程序里出现大量的“特殊情况”和“创可贴”。把一个“虫子”按下去,另一个虫子又冒出来。忙活来忙活去,最后仍然不能让程序满足“所有情况”。其实能够“满足所有情况”的程序,往往比能够“满足特殊情况”的程序简单很多。这是一个很奇怪的事情:能做的事越多,代码量却越少。也许这就叫做程序的“美”,它跟数学的“美”其实是一回事。
美的程序不可能从修修补补中来。它必须完美的把握住事物的本质,否则就会有许许多多无法修补的特例。其实程序员跟画家差不多,画家如果一天到头蹲在家里,肯定什么好东西也画不出来。程序员也一样,蹲在家里面对电脑,其实很难写出什么好的代码。你必须出去观察事物,寻找“灵感”,而不只是写代码。在修改代码的时候,你必须用“心灵之眼”看见代码背后所表达的事物。这也是为什么很多高明的程序员不怎么用调试器(debugger)的原因。他们只是用眼睛看着代码,然后闭上眼,脑海里浮现出其中信息的流动,所以他们经常一动手就能改到正确的地方。
http://kb.cnblogs.com/page/518955/
相关文章推荐
- 您可能无法使用服务器管理器,如果两个线程同时访问 IIS 管理 IIS 的修补程序
- 安装SQL Server 2000时出现以下错误提示:“以前的某个程序安装已在安装计算机创建挂起的文件操作,运行安装程序之前必须重新启动计算机” 说明:如果重启计算机无法解决问题,可能有以下两个原因
- 复制数据库时,必须要先停止Sql Server服务,才能复制.否则提示:无法复制,文件正在被另一个人或程序使用.
- Warning #2104: EXML解析警告,无法直接实例化自定义组件:ChatView ,在EXML中使用的自定义组件必须要能直接被实例化,否则可能导致后续EXML解析报错
- 2级C语言可能没过,数据结构必须开始,第一个目标手写程序突破100行
- Visual Studio .NET 无法创建或打开应用程序。问题很可能是因为本地Web服务器上没有安装所需的组件。请运行 Visual Studio .NET 安装程序并添加Web开发组件。
- Visual Studio .NET 无法创建或打开应用程序。问题很可能是因为本地Web服务器上没有安装所需的组件。请运行Visual Studio .NET安装程序并
- windows无法结束这个程序,要完成操作可能需要更多时间??
- 完美解决无法定位程序输入点 RtlDuplicateUnicodeString 于动态链接库 ntdll.dll 上
- (转)错误代码8004E00F-COM+无法与Microsoft分布式事物协调程序交谈。
- 解决xp下无法通过windows installer服务安装此安装程序包。您必须安装带有更新版本Wi
- “Visual Studio .NET 无法创建或打开应用程序。问题很可能是因为本地WEB本地服务器上没有安装所需的组件。请运行Visual Studio .NET安装程序并添加WEB开发组件“的一种解决方案
- 现在为了让程序兼容vista,我们需要给程序加上一个manifest文件,可是有时候vc6它就会弹出Resource Compiler Error RC2170 的错误,可能是vc6一个bug,我个人对vc6还是很喜欢的,不过经常会有编译死掉或出错的问题,
- Visual Studio .NET 无法创建或打开应用程序。问题很可能是因为本地WEB本地服务器上没有安装所需的组件。请运行Visual Studio .NET安装程序并添加WEB开发组件
- [转]解决Windows Installer 无法打开此修补程序包的问题
- 解决xp下无法通过windows installer服务安装此安装程序包。您必须安装带有更新版本Wi
- 由于虚拟机监控程序未运行,无法启动 Windows Phone Emulator。可能原因是为打开硬件辅助虚拟化。的解决方法
- cmd命令行执行java程序的编译和执行的方法及可能出现找不到或无法加载主类的错误的解决
- 必须冒着可能付出惨痛代价的风险前进,否则你就只能永远做个井底之蛙
- 无法通过windows installer服务安装此安装程序包。您必须安装带有更新版本windows Installer服务的Windows