5.9 KiB
AWTK 是如何保证代码质量的
这是不少朋友关心的问题，这里统一回复一下。我们在保证 AWTK 的代码质量方面，主要采用了下列措施：
-
架构设计。 软件架构对代码的质量有决定性的影响，但好的架构不是预先设计出来的，而是在应对各种需求和变化时，不断完善和优化出来的。常常见到，有人花十年时间打造一件绝世作品，也有人花几年时间让一套软件变成不可维护，这就是说明软件架构是在不断变化的，是变好还是变坏，则取决于开发者的意志。从一开始我们就把 AWTK 的架构优化放在首要地位，无论是增加新的功能还修改 BUG，每一次改动都 AWTK 的架构进行改进和优化。AWTK 的设计思想基本来自《系统程序员成长计划》，另外《设计模式》、《实时设计模式》、《软件框架设计的艺术》和《架构整洁之道》等书籍对 AWTK 架构的发展影响也很大。AWTK 的架构还有很大的改进空间，但我们相信通过不断的优化，AWTK 的架构会越来越完善。
-
单元测试。 代码的可测试对于单元测试至关重要，如果在设计系统架构时，没有考虑可测试性，那么单元测试是很难写的（请参考 Bob 大叔的《架构整洁之道》)。所幸在设计 AWTK 之初，我们就非常注重它可测试性。针对接口编程和依赖注入 (DIP) 是提高代码可测试重要的方法，在 AWTK 中有大量的接口和依赖注入，这使得 AWTK 绝大部分组件都可以编写单元测试。有人说单元测试只能解决 25%-50%的问题。我赞同这个观点，单元测试不是全能的，但它确实非常有用，我们也在不断完善 AWTK 的测试用例，让单元测试起到更大的作用。
-
Code Review。 Code Review 也是提高代码质量极好的手段，每次增加新的功能或修改 BUG，我们都会去 Review 相关的代码。在 Review 时，经常发现一些丑陋的代码，有时甚至完全不相信这些代码是自己写出来的，这时会庆幸进行了 Code Review，否则这些丑陋的代码就不被发现。通过 Code Review 发现这些丑陋的代码，并及时对其重构，不但让提高了代码的质量，还能有效防止破窗效应的出现。
-
在不同平台进行测试。 不同的平台、不同的编译器、甚至不同版本的操作系统和不同版本的编译器，都会发现新的问题。所以我们会定期在 MacOS，Linux、Windows 和各个嵌入式平台上进行测试，保证在各个平台上运行正常，这对提高代码质量也非常有用的。
-
对代码进行静态检查。 使用 cppcheck 和 facebook infer 进行静态检查。说实在的，如果平时写代码注意一点，静态分析的效果不大，偶尔能找出一个无关紧要的警告。
-
对代码进行动态检查。 用 C/C++写代码时，内存问题，比如：内存泄露、越界访问和野指针，这些问题引发的后果，可能随机出现，也可能很长时间后才出现，所以很难调试和定位。幸好动态检查对这类问题非常有效，valgrind 是一个强大且免费的动态检查工具，它能检查出绝大部分内存问题（与运行时代码的覆盖率有关）。可惜它支持 Linux 平台，而且对 SDL 支持不好。为了使用 valgrind，我们及时支持了 Linux Framebuffer，这使得我们可以用 valgrind 对 AWTK 进行全面检查。
-
手工测试。 手工测试也是必不可少的，我们会定期（基本上每天）手工把 demoui 中展现的功能测试一遍，有时会发现一些单元测试遗漏的问题或者无法自动测试的问题。
-
经常修改。 《架构整洁之道》中提出一个观点：要使软件架构稳定，你就要不断的修改它。这个观点初看有点自相矛盾，经常修改的东西会稳定吗？仔细一想，它又确实与我们过去多年的经验不谋而合：增加新功能时去完善它，在修改 BUG 去完善它，没事就去 Review 并重构它，架构自然越来越好，代码质量自然越来越高。当然，前提你的单元测试用例尽可能完善，否则没人敢去修改一个大型的代码。如果你关注 AWTK，你就会发现 AWTK 几乎天天都有很多改动，这些改动可能并没有增加新的功能。
-
群策群力。 ZLG 内部有不少同事在基于 AWTK 做项目，外部已经有不少公司开始使用 AWTK，他们也会发现一些漏网的问题，或提出一些新的需求。我们会及时响应这问题，对于严重的问题，基本上在当天都能解决。
对于一些特定平台出现的问题，我们没有重现的环境，希望发现问题的朋友，能静下心来去查找问题的原因，并分享出来。
- 自动化集成测试。 AWTK 实现了自动化测试引擎，兼容 appium 接口，轻松实现 UI 全自动化测试。详情请参考 awtk-ui-automation
在 AWTK 中，肯定还有很多问题，以上这些措施也并不全面，我们还在持续努力中。欢迎大家提出问题和建议，也欢迎大家去挖掘 AWTK 中 BUG 和丑陋的代码，用这些东西对我们进行"打脸"和"羞辱"。