<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>d.CAT- the RIA blog &#187; engineering</title>
	<atom:link href="http://ria.richtechmedia.com/category/engineering/feed/" rel="self" type="application/rss+xml" />
	<link>http://ria.richtechmedia.com</link>
	<description>a dedicated Flash&#124;Flex Rich Internet Application Blog from a senior Flex RIA developer/instructor</description>
	<lastBuildDate>Wed, 07 Apr 2010 02:39:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>unit test 與 AsUnit 3.0 &#8211; 關於 testing 與 test-driven的兩三事  (3/3)</title>
		<link>http://ria.richtechmedia.com/2005/11/16/unit-test-%e8%88%87-asunit-30-%e9%97%9c%e6%96%bc-testing-%e8%88%87-test-driven%e7%9a%84%e5%85%a9%e4%b8%89%e4%ba%8b-33/</link>
		<comments>http://ria.richtechmedia.com/2005/11/16/unit-test-%e8%88%87-asunit-30-%e9%97%9c%e6%96%bc-testing-%e8%88%87-test-driven%e7%9a%84%e5%85%a9%e4%b8%89%e4%ba%8b-33/#comments</comments>
		<pubDate>Wed, 16 Nov 2005 03:33:33 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>
		<category><![CDATA[flash]]></category>
		<category><![CDATA[tutorials]]></category>

		<guid isPermaLink="false">http://ria.richtechmedia.com/?p=295</guid>
		<description><![CDATA[testing這件事對許多工程師來說都是：知道它很重要，但從來不覺得應該去做。
在瞭解如何使用 AsUnit這樣一個 test framework後，接者就可以來談談目前一般人進行testing的方式。
比較傳統的做法是先寫程式，然後再做 unit test，也就是程式碼寫好後再用一堆 test case去驗証它的正確性，這種做法初看是非常合理的，也符合一般常見的專案開發流程，先規畫、再寫code、最後測試，然後上線(我們就叫這種為 waterfall開發法)
但這種做法也有不少的缺點，最明顯的一個就是等到全部的code都寫好時才要進行測試，往往會覺得無從下手，因此此時可能已經有數十個class，而且彼此的關連極深，根本不知道該怎麼測起，搞不好連當初寫的工程師自已都忘了某個class是做什麼用的(別笑，你試試看自已寫個class不加註解，然後半年後再拿出來，看看你還能記得多少內容或理解它在做什麼)。
另一個麻煩就是此時才進行測試，即使發現了錯誤，恐怕也很難修改，或是能改但成本變的很大，因為這時一改恐怕就要牽動好幾個其它class，天知道改了這裏其它地方會不會爆炸。
有鑑於此，90年代未期開始出現一種新的聲音，強調不如在寫程式前先把 test case寫好，然後再以通過測試為目標去開發程式，這就是所謂的 test-driven design。
舉個簡單的例子，以前面的money class為例，傳統的劇情是這樣：
1、我希望這個class可以加總兩筆金額，例如原本3元，加上5元後得到結果 8元
2、然後開始寫 Money.addMoney() 這支method：function addMoney(){....}
3、寫好後用幾組不同的數字傳入 addMoney() 去看看結果是否正確
而在 test-driven的劇情則是這樣：
1、我希望這個class可以加總兩筆金額，例如原本3元，加上5元後得到結果 8元
2、接者我先寫些測試的case 做為將來測試使用，例如 
PLAIN TEXT
Actionscript:




var money2:Money = new Money&#40; pounds2, pence2 &#41;;


var money3:Money = money.addMoney&#40; money2 &#41;


assertEquals&#40; "Pounds should be 6", 6, money3.pounds &#41;; 






3、然後開始寫 Money.addMoney() 這支method：function addMoney(){....}
但由於我已經知道將來會怎麼測試它，因此在寫的過程中就會特別留意傳入的參數與回傳的資料型態等細節要符合這個測試的期盼。
在 test-driven 的開發手法下，工程師寫程式是為了能百分之百通過 test case，因此在整個開發過程中就有了明確的依歸，只要test case有要求，就要在程式碼裏面完成(而且一定要完成)，而 test case [...]]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/11/16/unit-test-%e8%88%87-asunit-30-%e9%97%9c%e6%96%bc-testing-%e8%88%87-test-driven%e7%9a%84%e5%85%a9%e4%b8%89%e4%ba%8b-33/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>unit test 與 AsUnit 3.0 &#8211; tutorial  (2/3)</title>
		<link>http://ria.richtechmedia.com/2005/11/15/unit-test-%e8%88%87-asunit-30-tutorial-23/</link>
		<comments>http://ria.richtechmedia.com/2005/11/15/unit-test-%e8%88%87-asunit-30-tutorial-23/#comments</comments>
		<pubDate>Tue, 15 Nov 2005 03:02:50 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>
		<category><![CDATA[flash]]></category>
		<category><![CDATA[tutorials]]></category>

		<guid isPermaLink="false">http://ria.richtechmedia.com/?p=296</guid>
		<description><![CDATA[目前 asUnit的最新版是 asUnit 3.0.1 alpha，據兩位負責人說這是多年以來最大的改版，完全使用 actionscirpt 3 語法，並且忠實的照者 JUnit 去刻出一樣的功能，因此對大部份熟悉 JUnit使用方式的工程師來說，只要記得把 type 改成放後面並加上 : 就可以直接開工了。
下面簡單說明一下 asUnit 3的用法。
假設你有一個叫做 Money的class，它的功能是用來加減運算金額的數目
(note:這個程式是從 as2unit裏面借來的，我將它改寫成AS3 語法並修掉一些錯誤以通過測試)
PLAIN TEXT
Actionscript:




package&#123;


&#160; &#160; 


&#160; &#160; class Money&#160;&#123;


&#160; &#160; &#160; &#160; 


&#160; &#160; &#160; &#160; private var __pounds:Number;


&#160; &#160; &#160; &#160; private var __pence:Number


&#160; &#160; &#160; &#160; 


&#160; &#160; &#160; &#160; public function Money&#40; pounds:Number, pence:Number &#41;


&#160; [...]]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/11/15/unit-test-%e8%88%87-asunit-30-tutorial-23/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>unit test 與 AsUnit 3.0 &#8211; 介紹  (1/3)</title>
		<link>http://ria.richtechmedia.com/2005/11/14/unit-test-%e8%88%87-asunit-30-%e4%bb%8b%e7%b4%b9-13/</link>
		<comments>http://ria.richtechmedia.com/2005/11/14/unit-test-%e8%88%87-asunit-30-%e4%bb%8b%e7%b4%b9-13/#comments</comments>
		<pubDate>Mon, 14 Nov 2005 03:30:11 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>
		<category><![CDATA[flash]]></category>
		<category><![CDATA[tutorials]]></category>

		<guid isPermaLink="false">http://ria.richtechmedia.com/?p=294</guid>
		<description><![CDATA[unit test在專業的軟體開發過程中一直是非常非常重要的一環，透過一個有系統的方式來檢測程式碼的正確度可說是軟體開發最低限度的要求。
但到目前為止，10 個flash coders裏大概有 11 個都是用唯一的一種方式來做所謂的 test : CTRL-Enter，也就是 test movie來執行電影，然後看看output panel裏有無出現錯誤。(呃，如果你不屬於這11個，並且已經在用某種 unit test framework，那請直接跳過這篇文章去做更有意義的事，例如補個眠)
傳統用 test movie做測試對付小型的專案還行有餘力，但當案子發展的越來越大，並且完全走向 class (OO)導向的開發方式時，這種做法就顯的費時費力且不切實際，另一方面，這種測試方法往往要等UI好了才比較能整合起來測試，但往往這時有些根本的錯誤已經種的太深很難再改了。
在java的世界裏，這個問題很早就獲得了解決，他們可以靠一個叫 JUnit的 testing framework 來自動化所有的測試工作，只要簡單的設定與編輯，就可以完整的測試所有class中的每一個method運作是否正常，並且更重要的是，這些test class可以做為日後改版或 refactoring時重要依據，例如每次改完程式碼或refactor一大段code blcok, 就重跑一次test，只要測試能過，就代表剛才做的改變沒問題。 
在Flash的世界中其實也有類似JUnit的東西，幾個檯面上比較知名的(其實是也就只有這幾個啦)
-as2unit:
這是英國的 iteration:two顧問公司所發展的test framework,，as2unit的基礎架構是照者 JUnit翻版而來，但它只保留了幾個重要的部份，因此功能上不是非常完整。btw,  這家公司日前才剛被macromedia收購成為 Macromedia Europe Consulting (MEC)。
-as2lib：
這是最早期出現的一個全能型 library，裏面也包含了一個小型的 unit test library，但由於太冷門一直無法成為主流。
-flex unit：
這也是 iteration:two推出的project，但主要是針對 flex 做 unit test，只是隨者 flex 2的出現(與伴隨而來的大改良)，這個project結束的日子應該不遠了。
而本文要介紹的，則是由macromedia官方支援(金援)發展的正宗JUnit flash-port版：
AsUnit
asUnit也是一個open source的testing framework, 並且也存了在相當長一段時間，但由於一年前macromedia正式加入這個proejct，並且提供足夠的經費供他們做研發，因此他們順利的成為第一個支援Actionscript 3 的 [...]]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/11/14/unit-test-%e8%88%87-asunit-30-%e4%bb%8b%e7%b4%b9-13/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>工程師腦波強化特效藥</title>
		<link>http://ria.richtechmedia.com/2005/09/28/%e5%b7%a5%e7%a8%8b%e5%b8%ab%e8%85%a6%e6%b3%a2%e5%bc%b7%e5%8c%96%e7%89%b9%e6%95%88%e8%97%a5/</link>
		<comments>http://ria.richtechmedia.com/2005/09/28/%e5%b7%a5%e7%a8%8b%e5%b8%ab%e8%85%a6%e6%b3%a2%e5%bc%b7%e5%8c%96%e7%89%b9%e6%95%88%e8%97%a5/#comments</comments>
		<pubDate>Wed, 28 Sep 2005 11:00:52 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>

		<guid isPermaLink="false">http://ria.richtechmedia.com/?p=261</guid>
		<description><![CDATA[這標題聽起來很聳動，不過對我而言是挺有效。
經過這幾年的實驗，我發現聽的音樂類型對coding順暢度有很正面的影響，其中以 jazz 最有效，而 jazz 中又以鋼琴獨奏或trio的型式效果最好。
過去幾年凡是要做複雜的coding工作時，通常不二的選擇就是 Keith Jarret

Keith Jarret的獨奏鋼琴聽久了似乎可以安定腦波，有助延伸思路或預見許多原本不會發現的潛在地雷(bug)，以往許多神奇的架構規畫或implementation就是這樣不經意想出來的。
今天又重整了一次 iTune 的 folder，順便列一下常聽的 Keith Jarret 專輯：

At The Blue Note I Friday, June 3rd 1994 1st Set
At The Blue Note II Friday June 3rd 1994 2nd Set
At The Blue Note III Saturday, June 4th 1994 1st Set
At The Blue Note IV Saturday, June 4th 1994 2nd Set
At The [...]]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/09/28/%e5%b7%a5%e7%a8%8b%e5%b8%ab%e8%85%a6%e6%b3%a2%e5%bc%b7%e5%8c%96%e7%89%b9%e6%95%88%e8%97%a5/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>仿 flexstore 網站</title>
		<link>http://ria.richtechmedia.com/2005/08/20/%e4%bb%bf-flexstore-%e7%b6%b2%e7%ab%99/</link>
		<comments>http://ria.richtechmedia.com/2005/08/20/%e4%bb%bf-flexstore-%e7%b6%b2%e7%ab%99/#comments</comments>
		<pubDate>Fri, 19 Aug 2005 19:01:08 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>
		<category><![CDATA[flash]]></category>

		<guid isPermaLink="false">http://ria.richtechmedia.com/?p=220</guid>
		<description><![CDATA[公司網站

感謝yaya提供這個網站。(btw, 順便謝謝幫我測試原來右下角的留言版真的可以用  )
這是一個法國公司(一人?)做的仿 flexstore EC solution, 純手工用flash 硬拼出來。
晚上花了點時間玩了demo site順便看了一下程式碼，是用as1 + flash remoting v1 + amfphp完成的。
整個程式架構基本上是恐怖的spaghetti code，一堆的function分散在不同層次的movieclip，然後有大量的 onClipEvent()去觸發不同層級的事件。
另外主UI 上的三大塊panel也是用movieclip畫好3個keyframe擺上去的，這代表它絕不可能像flexstore裏的window元件可真正放大/縮小，而只能透過 onPress去觸發 gotoAndStop()變換到不同大小。
總之，整個程式架構跟寫法就跟自殺並無二致，恐怕再過三個月連當初寫的工程師都不認得裏面在做什麼，更別提將來其它人要接手維護或擴充功能時會面臨的挑戰。
(這也就是市場上為何總是有公司在找「維護合約」的廠商，而大部份有sense的廠商也都不願碰這種半路殺出的案子，因為誰也不願接手幫人家收拾善後，去修改一堆亂到不行的程式碼最後搞的自已也深陷泥沼動彈不得)
當然這並不是說不用物件導向或as2或Pattern/CBD寫程式就一定該死，國外也有不少高人寫的一手漂亮的as1(例如  flashmyadmin的darren就是近乎神人的例子)，重點是在於系統設計與架構的高明與否，以及寫程式的人本身對功能、責任區分的概念(例如MVC的每一塊意義與彼此溝通的方式)是否夠清楚，簡單一句話就是程式設計師的功力與觀念，決定了他能創作的境界高低。
這也正好呼應了joel 之前的說法，花貴的錢請最好的工程師，換來的收穫絕對比請一群二流的工程師高許多，因為 they can never hit the high note, they just don't have it. 
舉一個簡單的實例。
有位朋友，姑且稱作X桑，剛回台灣工作，幫某大銀行做data mining；他的任務就是從該金控龐大的資料庫中撈出可再撥一層皮的肥羊，呃，我是說可供幾百個業務電話行銷的尊貴客戶，而有趣也是令人驚訝的地方在於，該公司的資料庫中，光日期一欄，就可以撈出千百種不同的格式，例如以 民國 93 年 1 月1 日為例，裏面有的格式就包含：
-0930101
-930101
-20040101
-九三0101 
因此，到最後這位有為青年X桑主要的工作就是用sql function把這幾十種不同的日期格式統一換回西元日期(有興趣可以用MS SQL試試看這件事)
其它諸如此類不可思議的東西還有千百種。例如某卷商資料庫中，居然可以撈出下單日期比開戶日期早的資料(請問單子要下到那個戶頭去？)
但這是一家全國幾萬名從業員的大金控，裏面的資訊部門恐怕比大部份中小型資訊公司總人數都多，為何還會出現這種幾近可笑的錯誤？
答案很簡單。二萬八。
這是一個大學畢業剛進去寫程式的人起薪，而天兵日期格式可能就是在某年七、八月畢業季新人到職後寫下去的，一套系統經過幾年新人的反覆折騰，就成為今天這個樣子，終於有一天它會龐大到完全無法修改與維護，然後就是爆炸的時刻，接下來104上面就會出現一個「金融系統維護合約」....
我相信joel會提出「高等人才無價論」必然也是親眼看過二流工程師幹的好事與結果，才會有感而發~ 
這實在值得業主、資訊公司老闆跟工程師深思啊~
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/08/20/%e4%bb%bf-flexstore-%e7%b6%b2%e7%ab%99/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>hitting the high note !</title>
		<link>http://ria.richtechmedia.com/2005/07/31/hitting-the-high-note/</link>
		<comments>http://ria.richtechmedia.com/2005/07/31/hitting-the-high-note/#comments</comments>
		<pubDate>Sat, 30 Jul 2005 16:51:52 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>

		<guid isPermaLink="false">http://ria.richtechmedia.com/?p=197</guid>
		<description><![CDATA[臨睡前看到 joel 的這篇文章，實在太震撼，忍住睡意快寫下來。
這篇文章中joel提到他當年成立Fog Creek軟體公司的理念：
Best Working Conditions -> Best Programmers -> Best Software -> Profit!
他用了很長的篇符來解釋為何請最好的工程師對軟體公司很重要，原因如下：
-以生產軟體產品為主的公司，不像一般的製造業，例如wal-mart, 傳統製造業中人力成本越低，每件產品的單位成本就越低，因此製造業都會跑到東南亞設廠；但軟體產品的成本不會隨者銷售數量增加而倍增，一套產品寫出來後，成本只會隨者越賣越多而攤銷掉，不會上升。
-因此，一開始就請最好的工程師把產品寫好，這些成本反而可以更快回收。
Essentially, design adds value faster than it adds cost.
-好的工程師可以用更快更短的時間寫出更高品質的程式，這比請三個二流工程師還好，因為二流工程師只會把案子拖的更慢，效果更慘，而且永遠也生產不出一樣好品質的東西(人月真的只是神話)。
不過joel也提到，他的這套 高品質論 只適用於 software company, 而不是一般百大企業的IT部門，因為兩者的需求完全不同，就像沒有人會請dolly parton去婚禮唱歌一樣，她只適合大舞台。
全篇最讓人震撼的quote:
The mediocre talent just never hits the high notes, they just don't have it
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/07/31/hitting-the-high-note/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>什麼是 anti-pattern ?</title>
		<link>http://ria.richtechmedia.com/2005/05/19/anti-pattern/</link>
		<comments>http://ria.richtechmedia.com/2005/05/19/anti-pattern/#comments</comments>
		<pubDate>Thu, 19 May 2005 08:41:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>

		<guid isPermaLink="false">/?p=147</guid>
		<description><![CDATA[昨天的文章中出現 anti-pattern後，被很多人在msn上詢問到底是什麼意思，怎麼查不到這個pattern，GoF也沒提啊~
wiki的解釋
基本上 anti-pattern不是一個pattern，而是一堆亂例子的組合體，從字面上就可以感覺到這個意思。一般來說 design pattern是指好的應用，而 anti- 自然就是違反pattern的意思。
不過這個字的應用範圍實在太廣泛，因為在寫程式的過程中難免一定會犯錯(例如做了錯誤的決定、採用了錯誤的手法、或是想到要用pattern但卻implement錯誤結果更慘之類的)，所以這些錯誤都可以統稱為 anti-pattern。
當然如果你去amazon鍵入這個字的話，會找到幾本相關的書籍，有前輩們已經把常見的錯誤整理出來，或許看完可以瞬間增加一甲子功力吧~
_
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/05/19/anti-pattern/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>RIA 範例 &#8211; mediatuner.com</title>
		<link>http://ria.richtechmedia.com/2005/05/18/ria-mediatunercom/</link>
		<comments>http://ria.richtechmedia.com/2005/05/18/ria-mediatunercom/#comments</comments>
		<pubDate>Wed, 18 May 2005 06:40:17 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[actionscript]]></category>
		<category><![CDATA[engineering]]></category>

		<guid isPermaLink="false">/?p=145</guid>
		<description><![CDATA[
功能：Blog reader
特色：支援video blog與RSS
主要技術：php, xml, actionscript, js
介面做的很用心，把macromedia的ui元件都 re-skinning一遍，操作還算順暢，跟之前看到的 flash mail reader比起來算是好很多。
不過一看到程式碼就開始頭痛，果不其然這是一個 frame-based 的 procedural 產物，所有元件都宣告在同一個frame，所有的功能也是一個個的function四處散佈，這種程式最終的下場就是很難維護與debug，並且如果日後要新增不同的功能或業主要求能自訂版型layout甚至讓user換面板等細節，這位工程師將會身陷火海痛不欲生。
通常這種frame-based的RIA app 主要的問題都在於modulization程度不夠高，設計者缺乏基本的component-based design或物件導向觀念，一切只以「能快速達成眼前目標為出發點」，所以最後就會出現一個又一個的hack手法，也就是採取俗稱的"quick and dirty" way來寫程式。
這也是我在這篇裏所提過的諸多缺點之一，以及為何尋求正確的methodology/framework是很重要的原因。
不過往好的方面想，類似mediatuner 或 wallop 這樣的app，都是很好的 anti-pattern教材，當爛的例子一多時，量變總有造成質變的一天，有時多看壞的範例也是學習啊~
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/05/18/ria-mediatunercom/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>關於OR mapping好文一枚</title>
		<link>http://ria.richtechmedia.com/2005/05/16/or-mapping/</link>
		<comments>http://ria.richtechmedia.com/2005/05/16/or-mapping/#comments</comments>
		<pubDate>Mon, 16 May 2005 15:34:11 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[actionscript]]></category>
		<category><![CDATA[engineering]]></category>

		<guid isPermaLink="false">/?p=143</guid>
		<description><![CDATA[原文
他大致介紹了目前Java平台上幾個可用的選擇，並說明為何最後相中Hibernate。
基本上他的前進路徑與我相似，現在只差熱血青年出來寫一個  Hibernate for Actionscript 2了。(笑~)
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/05/16/or-mapping/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>本日字母湯 &#8211; SOA, CBD, PB/OOAD</title>
		<link>http://ria.richtechmedia.com/2005/05/15/soa-cbd-pbooad/</link>
		<comments>http://ria.richtechmedia.com/2005/05/15/soa-cbd-pbooad/#comments</comments>
		<pubDate>Sat, 14 May 2005 17:29:46 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[engineering]]></category>
		<category><![CDATA[flash]]></category>

		<guid isPermaLink="false">/?p=142</guid>
		<description><![CDATA[PB/OOAD: Pattern-Based Object Oriented Analysis and Design.
CBD: Component-Based Design.
SOA: Service Oriented Architecture.
這三個字真是 料多 實在 妙用無窮 啊~
任何一個好的、成熟的、複雜的專案，都應該遵照這三個原則，從一開始的規畫設計就整合Pattern與OO，並使用UML做為溝通的工具(我常用的幾種圖是 use case, class diagram, sequence diagram, ER，其它就隨緣了)，等A/D出來後，在實作階段就應該盡量採取Component-Based Design(在flash裏面，component可以是指單純的UI components，但也可以是多個UI components的集合單元)；而後端的部份則應該儘量採用SOA(不論是像.net的code behind, coldfusion的cfc或其它各種web service應用，總之後端服務應該有一定的封閉性，透過facade或adapter原理來操作)。
所以簡單來講，這三個字是有先後性的：
分析 - 前端實作 - 後端實作
PB/OOAD - CBD - SOA
雖然這三個字每個都不簡單，個個也都是大學問，但越早採用受益越多，對flash-based 的 RIA製作來說，比較大的難題可能是工程師得先從其它領域(.NET/JAVA)學會這些概念，然後再自行轉換到actionscript 2來，雖然過程中會造成進度遲緩，但就像大浪要來前必然會先退潮，退的越多後續沖上來的力道越強，一旦過了這個轉折之後就輕鬆了。
經過近兩個月的努力，最近我們終於完成一套貼近人性、彈性高又易用的framework(或稱做RIA best practice也行)，可以用最接近傳統win32 programming的方式達到快速開發(RAD)應用程式的效果，在未來幾個星期中我會將部份範例程式整理成教學文章放上來，請大家多指教。
ps. 經常被問到：為何我要這麼在意 方法論/framework/best practice/軟體工程 之類的東西，理由其實很簡單：
1、要認真開發商用軟體(不論是用flash/.net/java)，這都是必經的路，就跟做音樂一定要買mac是一樣的道理，雖然用其它方法也能達到類似效果，但路遙知馬力差別總有顯現出來的一天(而且往往會快的讓人嚇一跳)，所以與其繞路不如直指核心一次搞定最重要的部份。
2、受夠了flash向來惡名昭彰的惡搞開發流程，十個設計師寫出來的程式就會有二十種不同的手法跟三十種不同的錯誤加上四十個修不掉的bug，這一切會發生絕對都是有原因的，其中共通的一點就是在於先天缺乏正統的CS訓練，後天又沒有generally agreed-upon methodology可依循，再加上flash也是這一兩年才開始進入Application的開發領域，所以一切都太年輕、太混亂(不論是人、技術、市場皆是如此)。
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/05/15/soa-cbd-pbooad/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

