AWTK是如何保證代碼質量的呢

這篇文章給大家介紹AWTK是如何保證代碼質量的呢，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

AWTK是ZLG開源的GUI引擎，不少朋友關心AWTK是如何保證代碼質量的，這里統一回復一下。我們在保證AWTK的代碼質量方面，主要采用了下列措施：

• 架構設計。 軟件架構對代碼的質量有決定性的影響，但好的架構不是預先設計出來的，而是在應對各種需求和變化時，不斷完善和優化出來的。常常見到，有人花十年時間打造一件絕世作品，也有人花幾年時間讓一套軟件變成不可維護，這就是說明軟件架構是在不斷變化的，是變好還是變壞，則取決于開發者的意志。從一開始我們就把AWTK的架構優化放在首要地位，無論是增加新的功能還修改BUG，每一次改動都AWTK的架構進行改進和優化。AWTK的設計思想基本來自《系統程序員成長計劃》，另外《設計模式》、《實時設計模式》、《軟件框架設計的藝術》和《架構整潔之道》等書籍對AWTK架構的發展影響也很大。AWTK的架構還有很大的改進空間，但我們相信通過不斷的優化，AWTK的架構會越來越完善。

• 單元測試。 代碼的可測試對于單元測試至關重要，如果在設計系統架構時，沒有考慮可測試性，那么單元測試是很難寫的。所幸在設計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是一個強大且免費的動態檢查工具，它能檢查出絕大部分內存問題(與運行時代碼的覆蓋率有關)?？上С諰inux平臺，而且對SDL支持不好。為了使用valgrind，我們及時支持了Linux Framebuffer，這使得我們可以用valgrind對AWTK進行全面檢查。

• 手工測試。 手工測試也是必不可少的，我們會定期(基本上每天)手工把demoui中展現的功能測試一遍，有時會發現一些單元測試遺漏的問題或者無法自動測試的問題。

• 經常修改。 《架構整潔之道》中提出一個觀點：要使軟件架構穩定，你就要不斷的修改它。這個觀點初看有點自相矛盾，經常修改的東西會穩定嗎？仔細一想，它又確實與我們過去多年的經驗不謀而合：增加新功能時去完善它，在修改BUG去完善它，沒事就去Review并重構它，架構自然越來越好，代碼質量自然越來越高。當然，前提你的單元測試用例盡可能完善，否則沒人敢去修改一個大型的代碼。如果你關注AWTK，你就會發現AWTK幾乎天天都有很多改動，這些改動可能并沒有增加新的功能。

• 群策群力。 ZLG內部有不少同事在基于AWTK做項目，外部有些一些朋友開始使用AWTK，他們也會發現一些漏網的問題，或提出一些新的需求。我們會及時響應這問題，對于嚴重的問題，基本上在當天都能解決。

• 自動化集成測試。 這部分工作還沒有做，不過已經排入計劃。目前有兩個想法：一是支持事件的錄制和重放，并通過AI實現自動測試。二是支持appium等流行自動測試框架，用腳本對UI進行自動測試。

關于AWTK是如何保證代碼質量的呢就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。