最新公司产品需要全面优化加密算法，使用 AES-GCM 代替原来的 AES-CBC，我需要实现封装这个新的加解密接口。
实现这个基础方法，其实需要考虑的 case 还是挺多的，比如是否有多余的内存拷贝，针对无效输入做 buffer 越界保护，大小端以及各种异常情况下是否有内存泄漏等等。
这个基础方法并不复杂，但是考虑到所有产品线，所有客户端，甚至服务端都会调用这个接口做加解密，所以我们还是做了很多测试，以保证万无一失。
文档文档文档
文档非常非常重要，否则你每次都需要跟你的用户（基础库使用方）解释细节，直至暴走，怀疑人生。
代码 Review
代码 Review 常常能发现一些低级手抖错误，我实现这个方法时没有仔细考虑内存拷贝的开销，Review 代码时同事指出来了，后来想了一下，大量数据加解密调用时，频繁地内存拷贝可能会导致内存碎片，影响性能。
单元测试
单元测试简直是 Common SDK 开发者的保命法宝。我在 Chromium 工程源码是如何测试的 中提到过，Chromium 中所有基础库的代码都有大量的单元测试和性能测试。实现这个加解密方法时我写了大量的测试用例，测试了几波以后基本胸有成竹了。另外，如果产品源码编译时间很久的话，使用单元测试工程来开发会极大地提高效率。
Daniel Stenberg 大哥有一个 curl development with Daniel 系列，直播撸 curl 的 feature。围观了后，发现大哥也是写完代码后，用 testing 工程验证。
Fuzzing 测试
Fuzzing 测试就是传入各种无效、随机、操蛋的参数，测试方法是否有异常，比如 Crash, 内存泄漏等等。通常需要写一些脚本随机生成脏数据，然后频繁地调用目标方法。