好文：Flex 10 大錯誤(slightly revised)

Top 10 Mistakes when building Flex Applications

幾點有趣的 highlight 一下

#4. Slowing the application down by using XML for data transfer over optimized protocols.

如果可能，儘量不要用 XML，速度慢，造成的問題也多，改用 BlazeDS 或至少 AMF 是最優的選擇，行有餘力，捧個場買個 Live Cycle Data Services 也是很不錯的，至少 v2.6 裏用 NIO 重新改寫過 concurrency 變的非常好，一台撐幾千個 users 不是問題。

#3. Slowing the application down with the use of too many containers.

#6. Over use of animations

#9. Slowing the DataGrid down with complex renderers.

上面三項還只是眾多常見錯誤中最常見的幾個…在一個完整的開發過程中，保証是歡樂一籮筐處處皆地雷啊…

#1. Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff).

這是最常見的錯誤之一，公司興沖沖的採用了 flex，把一批 web developers 送去學完 flex 後動手開始寫，結果最後得到的是 flex 版的 html application，版面配置、操作方式完全一樣，唯一的差別是開發時程慢三倍，總成本增加五倍(因為後來發現寫出來的東西實在不能用，只好打掉用舊方法重練一次，或請外面的人重寫) <– 應大長輩之建議，此段特別標為紅色，使其重要性++

解決之道：look, before you JUMP.

#5. Trying to hire Flex developers.

Experienced Flex developers are very hard to find right now. Flex is at the point in the adoption curve which Java was at in the late nineties. The demand for Flex developers is exceeding the supply. This makes finding experienced Flex developers difficult. This, however, creates a huge opportunity for Java developers to expand their skill sets and work with a fun emerging technology. Many companies looking for Flex developers have great success training Java or other web application developers for only a few weeks on Flex. Flex’s language and APIs are easily learnable by developers who are familiar with Web and GUI programming.

(白話文：如果你以為 2005 – 2007 那段期間 flex 好手難尋？那可就錯了，現在才是真正困難的時刻，原因是早幾年 flex/air adoption rate 還沒那麼高，所以只要努力，打著燈籠一定可以在世界某個角落找到真正的好手，但從 2007 年底開始，adoption rate 急速拉高，因此早已呈現需求遠遠高於供給的現象，而早期的好手們早就卡好位置在某個企業或大公司裏穩穩的服務，或是開啟了自已的顧問事業，晚來的企業主要嘛花大錢請顧問公司提供真正一流的服務，要嘛就只能去 freelance 市場碰碰運氣了，至於想公開 hire 已成熟的高手級 flex developer 進到公司裏服務 ? 或許買張彩票運氣會好一點…)

說到 hiring 與才人供給，真是感觸特別深，以下再廢言數千字，要跳頁者現在是按 page down 的好時機…

———————————————-

如同文中所說，我試過找 java developer 然後訓練他們成為 flex developer，但事後証明，或許當初直接做換心或換腦手術可能效果比較好，主要原因不在於編程功力、資質，而是在於 mindset，說的更明白一點，每個人慧根與背景不同，很難 one size fits all (meaning: a java guru doesn’t necessarily make a good flex developer, ’cause it’s not all about coding but waaaaaaaay beyond that).

在我的經驗，資深的工程師普遍有個共通的特質：他們的優點也不幸的成為他們的缺點。

因為是很優的工程師，所以處理邏輯、架構、演算法這些事情上特別傑出，做的又快又好，寫的程式碼簡潔且有效率，如果他們能一直留在 faceless class 的世界(例如 server-side programming)那世界就會依然美好，可惜的是 flex 有著非常豐富的 UI DOM，它不像簡單的 html/javascript 就算搞爛了，也只是爛一頁，當 flex app 擺爛時，就是非同小可的大災難，而在開發過程中，有太多陷井等著讓工程師跳下去，不幸的是，因為缺乏 UI programming 的經驗，因此很容易就中招落馬。

更悲情的是，很多企業或主管仍然抱著『正港台灣人沒在怕』的態度(台語發音更有味喔)，認為反正工程師就是要給他/她/它(?)操到翻，丟下去上個課，特訓幾十個小時後回來就準備手牽手上工開發最 in 的 flex app 正式帶領企業邁向 RIA 的光明世界，基本上這種做法跟 『玩過 30小時 Flight Simulator 就宣稱自已會開飛機』是差不多的下場，不如直接把飛機炸了可能爽度還高一點 (有聽過爆破藝術嗎？) XD

簡單總結一下：

1、十年 server-side 編程經驗的 Java 老手，當他開始做 UI programming 時，程度其實跟小孩差不多，除非他那個前十年正好是在寫 SWT/SWING/Qt…

2、請後台工程師來寫 front-end client-side app，它造成的破壞等級跟殺傷力絕對是讓人大開眼界的，一個簡單的例子請看『不良 UI 又一例』這篇(我相信那就是某位可憐的 java 工程師被硬拉去順手寫幾頁 html…人家沒受過這種 UI 的訓練，寫出來的當然就是這種等級的東西，然後造成使用者不滿，算來算去這是誰的錯呢？

a. java工程師該死,
b. 逼 java 工程師去寫 UI 又不給適當訓練的主管該死,
c. 明知它爛還去用該網站的顧客該死

… 請作答 XD

3、okok, 我瞭解人性中一個永恆不滅的特質就是『懷疑』，什麼事情非要自已跌過一次才會相信，所以即使上面寫的落落長一篇，還是會有很多人認為：『騙肖，程式寫了幾十年哪會有無法搞定的技術，給它拼下去就對了』anyway, it’s a long and winding road ahead, we will see

延伸閱讀：台灣人勇於冒險，死不認錯，好騙難教 (把 台灣人 改成 地球人 就一體通用了)