作者: sjinny

静态信息的确是不完全的，但是有些东西最好还是让程序员自己来说明。比如说栈，你可以根据代码进行静态分析，让程序自己得出结论某个变量有明确的作用域。可是那只是一种结果，却不能反应程序员的意图。如果像C这样显式地说明栈，那么说明的就是程序员的意图：我不想让栈里的这些变量的作用域泄露到栈外。栈相当于微观上的模块边界，如果这些都要让程序去检测、去猜测，那么显然就是让程序去决定微观模块边界了。如果需求不变，那么代码形成的事实上边界就是程序检测出的，以这个边界来组织目标代码是没问题的。但是如果需求会变呢？当代码写完之后过了一段不长不短的时间后，当人不记得程序的细节之后，一段代码里如果没有程序员给出的显式边界，那么如何理解程序中各种变量的意图？即使读代码的人能够看出代码里事实上的边界，但是按照原先的设计，设计意图中的边界却得不到体现，于是就只知道这个变量目前的生存期可以压缩到某个范围，却不知道在这个范围之外对它的使用是否符合原先的设计，而且如果使用了某个超出了设计中的边界的变量，那么这时编译器是无法检测出来的，于是编译器本来能够检测的错误就无法检测出来了。如果代码里不能承载设计信息，那么也许一时之间没有问题，但是当一段时间之后，人遗忘了设计信息之后，这段代码就变得难以维护了。任何程序，也许能够了解这段代码目前的情况，也许能用各种技术进行扫描和推断，但是这些技术无法从根本上理解需求，所以它们获得的信息同样是不完全的。也许人对代码的了解不如这些分析程序多，但是人对需求的了解绝对多于这些程序，其实我认为这些程序无法理解需求。一段代码，如果要复用它，那么就要知道使用它的前提条件，以及使用它时要为它提供什么样的环境，所以一段代码自身附带的设计信息越多，越容易让人理解它，那么就越容易复用。