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和醜陋的代碼，用這些東西對咱們進行"打臉"和"羞辱"。