某问答平台上有一个有趣的问题：如果我能在一天内找到任何一个bug并修复，我能处于什么状态？编程领域？除了一些搞笑的回答，还有人觉得把这个技能应用到一个世界级的伟大项目上，可以创造很大的价值。我发现人们对错误的定义是多种多样且模糊的。主要分为两类：概念意义上的Bug，即代码中任何不符合人们需要的行为，都称为bug。程序意义上的bug，即代码在执行的时候不停，或者抛出错误，就叫做bug。如果我们从概念意义上围绕bug来讨论这个问题。很容易发散联想，把问题变成超能力小说创作。如果我们从程序意义上围绕bug来讨论这个问题，我们会发现这个能力实际上在做的是对代码的静态分析。也就是在不运行代码的情况下，分析代码的结构，判断能否正确运行。TypeChecking类型检查技术可以实现这种对代码的静态分析。在特定的TypeSystem类型系统下，推断程序是否接收到所有可能给定的输入，是否能正确输出指定类型的值。main:input->output将代码简化为一个main函数，其中input为参数类型，output为返回值类型。main函数执行可能的结果如下：限时接收输入类型参数，返回输出类型结果接收输入类型参数，永不停止执行，无返回值接收输入类型参数，执行时抛出错误（内部中间环节输出类型或类型匹配错误）根据以上三种结果，我们可以对主函数或主函数编写的语言进行分类：函数或语言的行为包括以上三种可能，函数或language只是第一个行为，输出指定类型的输出。我们称第二个为总的，第一个为部分的。你可以理解为total是指所有可能的输入都有正确类型的输出，即全无遗漏。Partial是指所有可能的输入，只有其中的一部分有正确的输出，不完整，有遗漏。回到那个问题，我可以在一天之内定位任何错误（程序意义上的）并给出修复，这可以认为等同于低效的TypeChecker类型检查程序。并且任何复杂的大型代码库都包含无数的类型错误，这些错误会导致不停或抛出错误。一个概念上的错误可能在相应的程序意义上有很多很多错误。这些错误中的大多数都是无害且微不足道的。一次耗费一整天的时间，定位一个低级类型的问题，然后给出简单的修改，这样的效率很难满足有价值的开发工作。所以，从程序意义上的bug来看，一天之内定位任何一个bug，由于类型检查的准确性，很有可能每次都会定位到代码中的第一个低级类型错误.任何lint或类型检查程序都可以在1秒内发现代码中的数千个错误（其中大部分是无关紧要的，不构成概念上的错误，而是程序中的错误）。换句话说，如果能在一天之内找到任何错误并修复，我就可以成为编程领域的低效类型检查员。如果没有彻底的类型检查，程序员修复一个错误可能会导致另一个错误或另一批错误的出现。大家的代码在严格的TypeChecker面前错漏百出，为什么会有那么多公司发布到生产环境，为什么我们大多数人还能比较正常的使用各种技术产品呢？这是因为，尽管用户数量众多，但产品运行过程、访问路径、行为数据等大部分是同质的，只占程序输入类型的很小一部分（例如理论值intnumber类型对应的成员数是无限的，实际值根据不同的语言有不同的bound，数量级通常很大).因此，即使代码是类型检查器的部分有效输入，也只有非常小的一部分具有正确的输出。但对于用户来说，这个很小的部分往往就足够了。要编写完整的代码，所需的类型系统能力是证明数学命题的水平。学习和开发成本都比较高。但是，使用相对不那么严谨的语言，用不太可靠的方式编写代码，从实用的角度来说，可以更快地构建出一定范围内可用的产品，并在后续迭代中不断扩大可用范围。这就是我们如何在不完美的代码中前进。
