當 Flex 專案變龐大，Building workspace (編譯專案) 的速度會變得極慢。不過野部也發現一些方法，可以大幅提升 Building workspace 的速度。
每次 Building workspace 之後，我們可以看到 0 errors, 0 warnings, 0 infos。提升速度的竅門，在於讓這三個數字都保持 0。 errors 並不可怕，因為修正之後，errors 並不會再次出現，拖慢 Building workspace 的速度。
真正可怕的是 warnings。warnings 的產生，野部歸納為下列幾種原因：

1. 函式的宣告，並未宣告 public 或 private，就直接以 function 開頭。
2. 函式的宣告，並未宣告類型，如 void、String、Number 等，就直接在 (…) 後接上 {…}。
3. 變數的宣告，並未宣告 public 或 private，就直接以 var 開頭。
4. 變數的宣告，並未宣告類型，如String、Number等，就直接以 ; 結束。
5. CSS 宣告的 Tag ，並未在 Application 的 MXML 中出現。
6. 外部 CSS 套用到 Custom component 上。

第 1 ~ 4 項，留心改善便可。第5、6項，其實是吃掉 Building workspace 的元兇。在Adobe / Macromedia 網頁設計工具中，例如 Flex、Dreamweaver、或是 Flash，針對 CSS 的運用時機，可分為 Design mode/time (設計時期之外觀) 和 Run time (執行時期之外觀)。
當我們在 Flex 使用 <mx:Style 標籤時，不論是外部或者內部 CSS，就是使用了 Design mode CSS。而每次存檔，Design mode CSS 都必須重新套用到整個專案，並輸出成 swf 檔，速度一定會很慢。
有時候，我們不得不將外部 CSS 套用到 Custom component (自訂元件，類似 Java Beans 的觀念，BCB or VB 也具有相同或類似的運作觀念)上。雖然外部 CSS 對 Custom component 的 Control (設計控件) 仍具有影響力，但是會出現一大串 warnings。
所以，野部提出幾個變通的方法。

1. 盡量減少 Custom component，改用 Application 搭配 SWFLoader，並根據不同的 Application 設計不同的外部 CSS。 每次 Custom component 的存檔，會影響所有引用這個 Custom component 的 MXML 重新編譯，這也是拖慢 Building workspace 的速度的另一個主因。
2. 用 Actionscript 產生 Control，不過這樣做，就走回 JAVA 在人機介面設計上，被人家詬病的老路了。不過野部知道，有些從 JAVA 領域來到 Flex 領域的設計師，極端偏好此道。優點是執行效率真的極端的高，缺點是這個專案無法讓太多不同背景的人共同 teamwork。如：視覺設計師、或專案經理。專案的邏輯只有程式設計師自己看得懂而已。萬一這位程式設計師離開專案，這專案就掛定了。
3. 將 Desing mode CSS Complie 成 Run time CSS。Run time CSS 的哲學是，程式開始執行才導入外部 CSS 去改變外觀。不但可以避開 Design mode CSS 重新套用的低效能，也不會產生任何 warnings。詳細做法，可參考 Flex Help 內的幾個主題：

1. Using external style sheets
2. Loading style sheets at run time

個人認為，上列三種方式，可靈活變通運用，不必極端。用得好，就是有效，用得不好，那就不如不用。

另外，針對除錯效率方面。雖然 Flex Builder 在 Eclipse 開發環境下，已經整合了自動提示 errors 的功能。可是過度依賴這個功能，是不好的觀念。而且，每次都讓開發環境去提示，可是得浪費掉很多效能和時間的。野部的 Flex 專案開發環境，最高消耗掉 700 多 mb 的記憶體。
正確的開發觀念是，一次就把程式寫對了，別讓開發環境來提醒。然而，弔詭的是，開發環境沒 errors，不見得寫下的程式就是對的。下面兩種情形，就是這樣的：

1. 某些 Default control 被 implement 時所呼叫的 Manager 有 bug，而我們並不知道這樣的 bug 存在。目前已知的情形是 ComboBox 所呼叫的 IPopUpManager 有這個情形。解決方法是要自行先 import 這個 Manager。聽說 DragManager也有。由於許多 Control 被 implement 都會使用到 IPopUpManger 和 DragManager，例如 ComboBox 或者 List，當發現下拉清單拉不下來時，就是了。所以，還是養成好習慣，調用 Manager 時，用和 JAVA 一樣嚴謹的態度完全 import，甚至開發環境沒有提醒到的，還是要強制 import。
2. 濫用的 parentApplication。在 Custom component 內的 parentApplication 語法會去參照引用這個 Application/Custom component 的最上層的 Application，不論中間引用的 n 層的 Application/Custom component。所以，可能是基於運算效能上的考量，開發環境並不會去偵測和除錯 parentApplication 語法，成了隱形的炸彈。parentApplication 絕對不是唯一的解決方案，還有很多寫法可以取代。parentApplication 用法可參考 Flex Help：

1. About the Application object
2. Passing data

還有一個小技巧，對設計師在 layout 上影響不大的一些 Control 就可以善加使用迴圈 + this[字串] 讓 Actionscript 自動產生或者批次處理大量的 Control，或者使用 repeater 達到同樣的目的。不但可以大幅減少 MXML 和 as 的檔案長度、增加程式的可讀性，並且不用重複撰寫多次類似的函式。

這些經驗的歸納，來自於野部不斷犯的錯，以及工作夥伴們，用血淚堆砌的開發經驗，希望對大家在開發 Flex 專案上，有所幫助。