上一次關注Qt Lighthouse是在6月初，可是現在都8月底了。時間真快...

Lighthouse 是 QPA(Qt Platform Abstraction) 項目的名字，它使得將Qt移植到新的平臺變得比較簡單。盡管現在它已經完全融入到了Qt主干代碼中，lighthouse作為獨立項目已經不復存在了，但本文中，我們繼續使用這個名字(雖然已不太恰當)。

QPA 抽象了什么？

不妨看看QPA前后，有何不同：

之前

考慮一下，傳統的Qt是如何實現圖形界面的夸平臺：

• 針對不同的窗口系統(WS)定義相應的宏： Q_WS_*

Q_WS_X11
Q_WS_MAC
Q_WS_QWS
Q_WS_WIN
Q_WS_S60

• 代碼中夾雜大量的編譯預處理指令 (處理小段)

#if defined(Q_WS_X11)
...
#elif defined(Q_WS_MAC)
...
#elif defined(Q_WS_WIN)
...
#endif

• 各個窗口系統相關的代碼文件 (處理大段)

qapplication_x11.cpp
qapplication_win.cpp
qapplication_s60.cpp
qapplication_mac.mm
qapplication_qws.cpp
...
qwidget_win.cpp
qwidget_qws.cpp
qwidget_mac.cpp
qwidget_x11.cpp
...

• src/gui/kernel.pri 等工程文件內，控制哪些文件參與編譯

win32 {
...
}
symbian {
...
}
unix:x11 {
...
}

這一切這意味這什么？？

如果我們想在這個基礎上支持一個新的窗口系統，比如wayland，需要

• 添加平臺相關的宏，代碼中針對該窗口再擴充 #if #elif #endif

• 添加平臺相關的文件，擴充 **.pri 文件使其融入Qt
• ...

總之，需要對Qt的代碼進行大量的修改。這一切使得將Qt移植到新的窗口系統中，變得不是那么容易。

之后

QPA 定義了一套接口，而后，將窗口系統相關的代碼放到插件中：

• src/plugins/platforms/xlib/*
• src/plugins/platforms/wayland/*
• src/plugins/platforms/cocoa/*

這時，如果我們想支持一個新的窗口系統，怎么辦？只需要編寫一個新的插件，而Qt自身的代碼則不需要任何改變。

(當然，編寫插件本身還是很有難度的，哈...)

QPA源碼結構

為了使插件能供工作，Qt中需要提供有相應的加載接口，在Qt源碼中搜索*_qpa.h、*_qpa.cpp、 *_qpa_p.h 即可找到所有(fixme)和 qpa有關的代碼：

• QTDIR/src/opengl
  • qgl_qpa.cpp
• QTDIR/src/gui
  • painting
    • qcolormap_qpa.cpp
    • qpaintdevice_qpa.cpp
  • image
    • qpixmap_qpa.cpp
  • egl
    • qegl_qpa.cpp
  • kernel
    • qplatformintegrationplugin_qpa.cpp
    • qplatformcursor_qpa.cpp
    • qwidget_qpa.cpp
    • ...
  • text
    • qfontengine_qpa.cpp
    • qfontengine_qpa_p.h
    • ...

可以看到代碼集中在 gui/kernel 部分；除此外，和字體相關gui/text，和繪圖相關gui/painting、gui/image、gui/egl，和opengl相關

QPA結構

QPlatformIntegration

這個應該算是 QPA 的核心了，

• 它是QApplication(準確地說是QApplicationPrivate)的成員

class Q_GUI_EXPORT QApplicationPrivate : public QCoreApplicationPrivate
{
...
    static QPlatformIntegration *platform_integration;
...

• 在初始化QAppliction時它會被創建

QApplication::QApplication()
  QApplicationPrivate::construct()
   qt_init()
     init_platform()
       QPlatfromIntegrationFactory::create()

• 它是所有窗口系統相關函數的入口點

class Q_GUI_EXPORT QPlatformIntegration
{
public:

這樣一來：

QPlatformWindow 與 QWindowSurface

相對而言，QPlatformWindow 出現的比較晚一點(見Say hello to QPlatformWindow一文）之所以。之所以分離開來，原因見Remodelling the Lighthouse。

QPlatformScreen

• 代表屏幕(顯示器)
• 它提供的api對應用程序來說是只讀的
• 用來計算分辨率 dpi

class Q_GUI_EXPORT QPlatformScreen : public QObject
{
...
    virtual QRect geometry() const = 0;
    virtual QRect availableGeometry() const {return geometry();}
    virtual int depth() const = 0;
    virtual QImage::Format format() const = 0;
    virtual QSize physicalSize() const;

QPixmapData

為什么要有這個東西？

通常我們似乎都不怎么區分QImage和QPixmap，盡管在Manual中很大的篇幅在描述這二者的區別。

設計目的和用途(一個是IO和像素操作，一個是屏幕顯示)：

• QImage is designed and optimized for I/O, and for direct pixel access and manipulation
• while QPixmap is designed and optimized for showing images on screen.

典型的用途：

• Typically, the QImage class is used to load an image file, optionally manipulating the image data, before the QImage object is converted into a QPixmap to be shown on screen.
• Alternatively, if no manipulation is desired, the image file can be loaded directly into a QPixmap.

與QImage不同，QPixmap 是平臺相關的

• Note that the pixel data in a pixmap is internal and is managed by the underlying window system.

于是它的后端需要由各個窗口系統來提供也就不足為奇了。

QPlatformFontDatabase

提供字體信息

詳見Fonts in Lighthouse一文。

其他

• QPlatformClipboard
• QPlatformCursor
• ...

同前面幾個一樣，從名字上容易看出是做什么的。

參考

• http://labs.qt.nokia.com/2010/04/06/remodelling-the-lighthouse/

• http://labs.qt.nokia.com/2010/04/21/say-hello-to-qplatformwindow/

• http://labs.qt.nokia.com/2010/09/02/fonts-in-lighthouse

最近讀了《卓有成效的程序員》，感覺收獲頗大。這是一本寫給程序員的難得的好書。書中大都是一些淺顯的道理，但作者將這些東西加以收集、歸納、總結，并最終成書。作者為了收集各種提高效率的工具和方法，東奔西走，可謂費了一番苦心。

我覺得此書第一部分總結的一些法則非常好，我提取了一下：

法則： 

1.加速法則

    關注本質，而非形式

    一個應用程序列表的有用程度與它的長度成反比 

    程序員的很多時間都浪費在找東西上 

    華而不實的東西中看不中用

    鍵盤輸入總比導航快

    首選鍵盤而非鼠標

    地址欄是Windows資源管理器界面中最高效的部分

    花點時間來學習你手邊的所有隱藏的快捷鍵

    環境切換會消耗時間

    成批復制粘貼要比反復多次復制粘貼快

    忘記歷史就意味著你得再輸入一遍

    嵌入圖形化工具的命令提示符讓你魚與熊掌兼得

    在上下文中學習IDE快捷鍵，而不要去背長長的列表

    當你第二次輸入一個復雜結構時，將它做成模板

    如果要對多行文本做同樣的操作，就應該找出其中的模式，并把它記錄為一個宏

    不要總是重復輸入相同的命令

    每天花一點點時間來使每一天都更高效 

2.專注法則

    精力越集中，思維越縝密

    排除干擾：隔離策略，關掉不需要的提示，創造安靜時間  

    草堆越大，從中找到一根針就越難

    不要問文件樹，要搜索

    使用多顯示器

    虛擬桌面可以讓原本雜亂無章的一大堆窗口變得整潔 

3.自動化法則

    不要重新發明輪子

    用Selenium瀏覽網頁

    不要浪費時間動手去做可以被自動化的事情

    用Windows Power Shell替代批處理文件

    馴服Subversion命令行

    以創造性的方式解決問題，有助于在將來解決類似的問題

    是否應該自動化的關鍵在于投資回報率和緩解風險

    研究性的工作應該放在時間盒里做

    別給牦牛剪毛 

4.規范性法則

    對于任何你不自己去構建的東西，只在版本控制中保存一份副本

    使用標準的構建服務器

    通過復制粘貼來復用是邪惡的，不論你復制粘貼的是什么

    利用虛擬平臺使項目依賴標準化

    不要讓對象 - 關系映射工具（O/R映射器）違反規范原則 

    通過擴展。開放類（open class），或者部分類（partial class） 來為生成的代碼增加行為

    始終保持代碼和數據結構的同步

    過時的文檔比沒有文檔更糟，因為它會主動誤導你

    任何需要費勁創造的東西，都讓它的創造者欲罷不能

    白板 + 數碼相機強過任何CASE工具

    盡量生成所有技術文檔

    重復是軟件開發中最大的阻力 

工具：

書中，還提到了大量的提高效率的工具，都是非常不錯的。相信很多人都有自己的一個列表，下面是我電腦中必不可少的幾款軟件：

    1. FireFox 及其各類插件

    2. Launchy啟動加速器

    3. Total Commander

    4. ClipX多重剪切板

    5. EmEditor文本編輯器 

    6. Vistual Studio的VA插件

    7. Search And Replace

    8. Everything

    9. Miranda IM

    10. .... 

感觸： 

1. 憤怒的猴子 

在書中的第二部分，提到了很多實踐相關的內容。讓我感觸最深的是“憤怒的猴子”的故事：

“早在20世紀60年代（那時候科學家們可以做任何瘋狂的事情），行為科學家們進行了一項實驗。他們把五只猴子和一架活梯放在一間屋子里，并在天花板上掛了一串香蕉。這些猴子很快就想到它們可以爬上梯子去吃香蕉，但每當它們靠近活梯的時候，科學家們就用冰水浸滿整個屋子。我想你能猜到會發生什么：一群憤怒的猴子。很快，再沒有一只猴子會去靠近那個梯子了。

之后，科學家們將其中一只猴子替換成另一只沒有忍受過冰水折磨的新猴子。這只新猴子所做的第一件事就是直奔那架梯子，但當它這么做時其他所有猴子都痛打它。它不明白為什么，但很快就學乖了：不要去靠近那架梯子。科學家們逐漸將最初的那些猴子都替換成新猴子，直到這群猴子中誰都沒有被水浸泡過，然而它們還是會去攻擊任何靠近梯子的猴子。

這說明了什么？軟件項目中許多慣例之所以存在，就因為”我們一直是那樣做的“。換句話說，是因為憤怒的猴子。”

我們小組在制定C++相關的代碼規范時就遇到過無數類似的問題。比如，在制定變量的命名規范時，我們針對是否采用匈牙利命名法爭論了很久。有的人認為， 幾乎以前看到的所有C++代碼都采用了匈牙利命名法，甚至，微軟定義的所有API都使用了此類命名法。剛開始，我也是有同樣的疑惑。

后來，我們經過仔細分析C++匈牙利命名法由來，漸漸感覺我們就是那些憤怒的猴子，盲目跟從前人的方式，缺乏打破傳統的勇氣。C++有著其特殊的歷史原因，很多標準一直沉淀下來并很少改變。我們再看看后來新生的那些編程語言，C#, Python…… 都拋棄了匈牙利命名法，同時再看看現在C++前沿的C++ 0x以及現在出版的一些書中，也漸漸放棄了對匈牙利命名法的使用。因為類型的意義在對象模型中越來越弱化。因此，最后我們放棄了匈牙利命名法這個老古董。 

2. 敏捷開發

這本書帶有強烈的ThoughtWorks色彩，敏捷的思想貫穿全書，包括測試驅動設計，白板，結對編程。這也讓我對敏捷產生了更加強烈的興趣。 其中有一段測試驅動開發TDD的一段故事：

“記得第一次和一些已經習慣于單元測試的開發人員一起動手開始修改代碼時，我也是非常緊張，因為大量的修改往往會破壞很多東西，但他們看起來絲毫沒有猶豫。逐漸地，我也放下心來，因為我慢慢地認識到：有了測試的保證，完全可以放心大膽地去修改代碼。” 

3. 有趣的故事 

書中還有一些有趣的故事，比如作者的一個朋友在和別人結對編程時，為了養成同伴使用快捷鍵的習慣，每當同伴未使用快捷鍵時，他都會要求將操作撤銷，然后要求使用快捷鍵再重復操作3次。然后，在其兇狠的眼神中，同伴很快掌握了快捷鍵。 

總結：

這本書很薄，蘊藏的道理卻不少，相信每個讀過它的人都會從中收獲。讀過之后，我們不應該局限于書中提到的某些小技巧， 或是書中某一個細節，畢竟，提供效率的方法有很多很多，法則也有很多很多，一本書很難將其窮舉完。我們應該從書中吸取其思想，并在實際工作和學習中不斷總結，做一個真正的“卓有成效的程序員”！

剛接觸單元測試時，我實在是搞不懂這種測試到底有多大的意義，無非都是一些簡單的ASSERT，但近年積累一些經驗教訓之后我才發現，單元測試這玩意兒真的是一種保證程序質量的強有力手段。

為什么這樣說？舉個最典型的例子，無論是開發新功能還是維護老程序，都不可避免的要反復修改某些代碼，那該怎么保證修改的代碼不會引入新的問題？如果你說你用人品擔保，那我服了。我們應該需要一種可靠的手段來保證修改一個BUG不會引入兩個三個BUG，或者不會讓之前正確的功能出錯，甚至是不會引入之前已經修改過的其它BUG。測試無疑是一種很好的手段，在沒掌握其它更好的方法之前，很多人喜歡用人工測試，即編譯 – 運行 – 輸入典型值 – 看程序運行結果 – 如果出錯 – 修改后再編譯……從長遠來看，這種測試方法的缺點很明顯：1、耗時耗力，每次修改代碼后都需要人工重復測試所有的典型情況；2、容易出錯、漏測，人腦太復雜，你很難記得幾個月前的那個BUG到底是什么情況，因此沒法測試，久而久之，N久前的那個BUG可能又神不知鬼不覺的重現了。相比之下，單元測試的優點就凸顯出來了，把需要測試的典型情況編寫為測試代碼，然后編譯運行即可完成自動化的測試，當發現BUG后，把它添加到測試用例，不僅可以提高測試覆蓋率，還能保證以后不會再次引入同樣的BUG，有了足夠的單元測試（覆蓋率），你就可以理直氣壯的說代碼沒問題！當然引入單元測試會在前期花費不少的時間來編寫測試代碼，但相應的也會大大減少后期的維護工作，最主要的是能可靠的提高程序的質量，所以是值得的，甚至是必要的。（如果你編譯過開源的Google Chromium瀏覽器，你會發現測試代碼就占了不少，光是編譯測試代碼就得花很長的時間）

除了上面說的優點外，單元測試還有一些其它的好處，比如幫你理清設計。一些人反對單元測試就是因為說我們的應用太復雜了，沒法做單元測試。其實不一定是應用復雜，而有可能是設計得有問題，導致了沒有可測試性。比如有些人喜歡在CXXXDialog里編寫所有的功能實現，要測試這樣的代碼，必須得創建出Dialog，可能還需要點擊，這顯然沒法做單元測試，但如果把Dialog和業務邏輯分開設計，那至少業務邏輯是可測試的（暫不討論UI的測試）。因此要做單元測試，就得設計好各個接口，保證某個接口只完成單一的功能，沒有過多的耦合依賴。

前面只是泛泛而談了一些單元測試的皮毛，鼓吹了一些優點，有興趣的自己找更詳細的資料看吧。另推薦一個Google的開源C++測試框架googletest。