Formal methods with Hillel Wayne

关键观点

1. 01

   形式化方法从显式化意图开始

   形式化工作的第一步不是证明，而是把开发者对程序行为的隐含认识转化为清晰、无歧义的规格。例如，列表最大值不仅是某个测试用例的预期结果，还必须属于该列表，并且不小于任何其他元素。规格描述“应该做什么”，验证则判断实现是否满足规格。完整形式化验证追求覆盖所有可能输入，而不是少数人工挑选的案例。

   为什么重要: 如果无法准确表达预期行为，再强的证明工具也只能证明实现符合一个可能错误或空洞的规格。

   支撑证据

   Can we figure out what a function is supposed to actually be doing and write that down in a way that can be shown to anybody?

   形式化工作的第一步不是证明，而是把开发者对程序行为的隐含认识转化为清晰、无歧义的规格。例如，列表最大值不仅是某个测试用例的预期结果，还必须属于该列表，并且不小于任何其他元素。规格描述“应该做什…展开观点

   形式化工作的第一步不是证明，而是把开发者对程序行为的隐含认识转化为清晰、无歧义的规格。例如，列表最大值不仅是某个测试用例的预期结果，还必须属于该列表，并且不小于任何其他元素。规格描述“应该做什…展开观点收起观点

   形式化工作的第一步不是证明，而是把开发者对程序行为的隐含认识转化为清晰、无歧义的规格。例如，列表最大值不仅是某个测试用例的预期结果，还必须属于该列表，并且不小于任何其他元素。规格描述“应该做什么”，验证则判断实现是否满足规格。完整形式化验证追求覆盖所有可能输入，而不是少数人工挑选的案例。

   为什么重要: 如果无法准确表达预期行为，再强的证明工具也只能证明实现符合一个可能错误或空洞的规格。

   支撑证据

   Can we figure out what a function is supposed to actually be doing and write that down in a way that can be shown to anybody?

2. 02

   规格成本阻止形式化验证覆盖一切

   简单数学函数容易定义，但真实程序会迅速牵涉编码、权限、快捷方式、目录类型和具体文件系统等上下文。此时，准确写出函数在所有情况下应该如何响应，可能成为一项庞大的建模工作。对多数低风险功能，覆盖主要路径的测试和一个在绝大多数情况下正确的实现已经足够。追求百分之百的完整性，未必能产生合理的投入回报。

   为什么重要: 是否采用形式化方法，应由错误成本、系统复杂度和规划需求决定，而不是把它当作所有项目的默认最佳实践。

   支撑证据

   when you start talking about like most interesting domain problems, you have to pull in so much context that basically even writing what the function is supposed to do becomes a nightmare.

   简单数学函数容易定义，但真实程序会迅速牵涉编码、权限、快捷方式、目录类型和具体文件系统等上下文。此时，准确写出函数在所有情况下应该如何响应，可能成为一项庞大的建模工作。对多数低风险功能，覆盖主…展开观点

   简单数学函数容易定义，但真实程序会迅速牵涉编码、权限、快捷方式、目录类型和具体文件系统等上下文。此时，准确写出函数在所有情况下应该如何响应，可能成为一项庞大的建模工作。对多数低风险功能，覆盖主…展开观点收起观点

   简单数学函数容易定义，但真实程序会迅速牵涉编码、权限、快捷方式、目录类型和具体文件系统等上下文。此时，准确写出函数在所有情况下应该如何响应，可能成为一项庞大的建模工作。对多数低风险功能，覆盖主要路径的测试和一个在绝大多数情况下正确的实现已经足够。追求百分之百的完整性，未必能产生合理的投入回报。

   为什么重要: 是否采用形式化方法，应由错误成本、系统复杂度和规划需求决定，而不是把它当作所有项目的默认最佳实践。

   支撑证据

   when you start talking about like most interesting domain problems, you have to pull in so much context that basically even writing what the function is supposed to do becomes a nightmare.