mirror of
https://gitee.com/zlgopen/awtk.git
synced 2024-12-05 05:27:58 +08:00
27 lines
5.7 KiB
Markdown
27 lines
5.7 KiB
Markdown
# [AWTK](https://github.com/zlgopen/awtk)是如何保证代码质量的
|
||
|
||
这是不少朋友关心的问题,这里统一回复一下。我们在保证[AWTK](https://github.com/zlgopen/awtk)的代码质量方面,主要采用了下列措施:
|
||
|
||
* **架构设计。** 软件架构对代码的质量有决定性的影响,但好的架构不是预先设计出来的,而是在应对各种需求和变化时,不断完善和优化出来的。常常见到,有人花十年时间打造一件绝世作品,也有人花几年时间让一套软件变成不可维护,这就是说明软件架构是在不断变化的,是变好还是变坏,则取决于开发者的意志。从一开始我们就把[AWTK](https://github.com/zlgopen/awtk)的架构优化放在首要地位,无论是增加新的功能还修改BUG,每一次改动都[AWTK](https://github.com/zlgopen/awtk)的架构进行改进和优化。[AWTK](https://github.com/zlgopen/awtk)的设计思想基本来自《系统程序员成长计划》,另外《设计模式》、《实时设计模式》、《软件框架设计的艺术》和《架构整洁之道》等书籍对[AWTK](https://github.com/zlgopen/awtk)架构的发展影响也很大。[AWTK](https://github.com/zlgopen/awtk)的架构还有很大的改进空间,但我们相信通过不断的优化,[AWTK](https://github.com/zlgopen/awtk)的架构会越来越完善。
|
||
|
||
* **单元测试。** 代码的可测试对于单元测试至关重要,如果在设计系统架构时,没有考虑可测试性,那么单元测试是很难写的(请参考Bob大叔的《架构整洁之道》)。所幸在设计[AWTK](https://github.com/zlgopen/awtk)之初,我们就非常注重它可测试性。针对接口编程和依赖注入(DIP)是提高代码可测试重要的方法,在[AWTK](https://github.com/zlgopen/awtk)中有大量的接口和依赖注入,这使得[AWTK](https://github.com/zlgopen/awtk)绝大部分组件都可以编写单元测试。有人说单元测试只能解决25%-50%的问题。我赞同这个观点,单元测试不是全能的,但它确实非常有用,我们也在不断完善[AWTK](https://github.com/zlgopen/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](https://github.com/zlgopen/awtk)进行全面检查。
|
||
|
||
* **手工测试。** 手工测试也是必不可少的,我们会定期(基本上每天)手工把demoui中展现的功能测试一遍,有时会发现一些单元测试遗漏的问题或者无法自动测试的问题。
|
||
|
||
* **经常修改。** 《架构整洁之道》中提出一个观点:要使软件架构稳定,你就要不断的修改它。这个观点初看有点自相矛盾,经常修改的东西会稳定吗?仔细一想,它又确实与我们过去多年的经验不谋而合:增加新功能时去完善它,在修改BUG去完善它,没事就去Review并重构它,架构自然越来越好,代码质量自然越来越高。当然,前提你的单元测试用例尽可能完善,否则没人敢去修改一个大型的代码。如果你关注[AWTK](https://github.com/zlgopen/awtk),你就会发现[AWTK](https://github.com/zlgopen/awtk)几乎天天都有很多改动,这些改动可能并没有增加新的功能。
|
||
|
||
* **群策群力。** ZLG内部有不少同事在基于[AWTK](https://github.com/zlgopen/awtk)做项目,外部有些一些朋友开始使用[AWTK](https://github.com/zlgopen/awtk),他们也会发现一些漏网的问题,或提出一些新的需求。我们会及时响应这问题,对于严重的问题,基本上在当天都能解决。
|
||
|
||
>对于一些特定平台出现的问题,我们没有重现的环境,希望发现问题的朋友,能静下心来去查找问题的原因,并分享出来。
|
||
|
||
* **自动化集成测试。** 这部分工作还没有做,不过已经排入计划。目前有两个想法:一是支持事件的录制和重放,并通过AI实现自动测试。二是支持[appium](https://github.com/appium/appium)等流行自动测试框架,用脚本对UI进行自动测试。
|
||
|
||
在[AWTK](https://github.com/zlgopen/awtk)中,肯定还有很多问题,以上这些措施也并不全面,我们还在持续努力中。欢迎大家提出问题和建议,也欢迎大家去挖掘[AWTK](https://github.com/zlgopen/awtk)中BUG和丑陋的代码,用这些东西对我们进行"打脸"和"羞辱"。
|