AWTK是如何保证代码质量的

AWTK是ZLG开源的GUI引擎，很多朋友关心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和各个嵌入式平台上进行测试，保证在各个平台上运行正常，这对提升代码质量也很是有用的。

• 用valgrind进行动态检查。 用C/C++写代码时，内存问题，好比：内存泄露、越界访问和野指针，这些问题引起的后果，可能随机出现，也可能很长时间后才出现，因此很难调试和定位。幸亏动态检查对这类问题很是有效，valgrind是一个强大且免费的动态检查工具，它能检查出绝大部份内存问题(与运行时代码的覆盖率有关)。惋惜它支持Linux平台，并且对SDL支持很差。为了使用valgrind，咱们及时支持了Linux Framebuffer，这使得咱们能够用valgrind对AWTK进行全面检查。

• 手工测试。 手工测试也是必不可少的，咱们会按期(基本上天天)手工把demoui中展示的功能测试一遍，有时会发现一些单元测试遗漏的问题或者没法自动测试的问题。

• 常常修改。 《架构整洁之道》中提出一个观点：要使软件架构稳定，你就要不断的修改它。这个观点初看有点自相矛盾，常常修改的东西会稳定吗？仔细一想，它又确实与咱们过去多年的经验不谋而合：增长新功能时去完善它，在修改BUG去完善它，没事就去Review并重构它，架构天然愈来愈好，代码质量天然愈来愈高。固然，前提你的单元测试用例尽量完善，不然没人敢去修改一个大型的代码。若是你关注AWTK，你就会发现AWTK几乎每天都有不少改动，这些改动可能并无增长新的功能。

• 群策群力。 ZLG内部有很多同事在基于AWTK作项目，外部有些一些朋友开始使用AWTK，他们也会发现一些漏网的问题，或提出一些新的需求。咱们会及时响应这问题，对于严重的问题，基本上在当天都能解决。

对于一些特定平台出现的问题，咱们没有重现的环境，但愿发现问题的朋友，能静下心来去查找问题的缘由，并分享出来。

• 自动化集成测试。 这部分工做尚未作，不过已经排入计划。目前有两个想法：一是支持事件的录制和重放，并经过AI实现自动测试。二是支持appium等流行自动测试框架，用脚本对UI进行自动测试。

在AWTK中，确定还有不少问题，以上这些措施也并不全面，咱们还在持续努力中。欢迎你们提出问题和建议，也欢迎你们去挖掘AWTK中BUG和丑陋的代码，用这些东西对咱们进行"打脸"和"羞辱"。