#杂
这段时间给Databend增加增删列的功能，基本功能已经通过，加了如下截图的用例，目的是验证一顿增删列、插入数据之后的查询都是正确的。
可还是很忐忑，因为这个功能涉及了很多对原有数据格式的修改，要保证所有场景都兼容到了。
我最近复习数学，反过来看，编程在大部分时候，都不能算是“科学”，更多算是“工程”。个中原因，我认为大部分时候，无法从数学角度严格证明一个功能是100%完全没有bug的。
复杂参数的场景姑且不论，就以最简单的整数为参数的问题来说。数学归纳法的原理是先证明n=1的时候结论成立，再假设为n的时候结论成立，最后以这个为前提来证明n+1时结论成立，这在数学上是可行的。但是呢，来到编程领域，一个“千年虫”问题，不过就是表示年份的整数划到了2000而已，就能触发bug了，数学归纳法在这里失效了。
在知乎上看到过著名的“一个测试工程师走进一家酒吧”：
“
一个测试工程师走进一家酒吧，要了一杯啤酒
一个测试工程师走进一家酒吧，要了一杯咖啡
一个测试工程师走进一家酒吧，要了0.7杯啤酒
一个测试工程师走进一家酒吧，要了-1杯啤酒
一个测试工程师走进一家酒吧，要了2^32杯啤酒
...
”
很多时候人们当成段子来看，但是现实中就是这样，无法去归纳某个场景的测试就是完备的，只能靠：堆用例的场景去验证。
sqlite是业内最稳定的数据库之一，号称几万个用例，可即便是它的作者也不敢打包票100%无bug，也是一边补充用例一边增加现有用例。
总而言之，一个事情如果无法用数学原理严谨证明其正确性，总会出问题；反过来说，编程在大部分时候无法用数学证明其正确性，所以编程不是科学，更接近于工程：靠经验、靠堆用例等等手段去保证（而不是验证）其正确性。
这段时间给Databend增加增删列的功能，基本功能已经通过，加了如下截图的用例，目的是验证一顿增删列、插入数据之后的查询都是正确的。
可还是很忐忑，因为这个功能涉及了很多对原有数据格式的修改，要保证所有场景都兼容到了。
我最近复习数学，反过来看，编程在大部分时候，都不能算是“科学”，更多算是“工程”。个中原因，我认为大部分时候，无法从数学角度严格证明一个功能是100%完全没有bug的。
复杂参数的场景姑且不论，就以最简单的整数为参数的问题来说。数学归纳法的原理是先证明n=1的时候结论成立，再假设为n的时候结论成立，最后以这个为前提来证明n+1时结论成立，这在数学上是可行的。但是呢，来到编程领域，一个“千年虫”问题，不过就是表示年份的整数划到了2000而已，就能触发bug了，数学归纳法在这里失效了。
在知乎上看到过著名的“一个测试工程师走进一家酒吧”：
“
一个测试工程师走进一家酒吧，要了一杯啤酒
一个测试工程师走进一家酒吧，要了一杯咖啡
一个测试工程师走进一家酒吧，要了0.7杯啤酒
一个测试工程师走进一家酒吧，要了-1杯啤酒
一个测试工程师走进一家酒吧，要了2^32杯啤酒
...
”
很多时候人们当成段子来看，但是现实中就是这样，无法去归纳某个场景的测试就是完备的，只能靠：堆用例的场景去验证。
sqlite是业内最稳定的数据库之一，号称几万个用例，可即便是它的作者也不敢打包票100%无bug，也是一边补充用例一边增加现有用例。
总而言之，一个事情如果无法用数学原理严谨证明其正确性，总会出问题；反过来说，编程在大部分时候无法用数学证明其正确性，所以编程不是科学，更接近于工程：靠经验、靠堆用例等等手段去保证（而不是验证）其正确性。