29 August 2005

逛 Blog 發現一篇不錯的 Top 5 and bottom 5 Principles of Enterprise Architecture from the summit。裡面替 2005 Enterprise Architecture Summit 作了一些總結。以前居然不知道有這種高峰會!乖乖,討論的東西不僅是現在最先進的,而且也能點出未來的發展方向,不得了!看看參加的人有誰吧:發起人 Bruce Eckel (Thinking in Java 等書作者) 以及 Martin Fowler (Refactoring 等書作者)。參加的人有 Rod Johnson (Spring 發起人)、Patrick Linskey (Bitter EJB 作者)、 Gregor Hohpe(Enterprise Integration Patterns 作者)、Eric Evans (Domain Driven Design 作者) blah blah blah 都是一些重量級的人物,不認識他們嗎,這裡有照片。呼~~ 不難想像會併出什麼樣的火花,真希望能夠實際聽聽他們討論的內容。

Anyway,回到主題 -- 企業架構的五個最高準則。這是與會人員從 40 個候選準則中,投票後的結果:

  • 1) Use a layered architecture.
  • 2) Build Automated Regression Tests
  • 2) Manage your application as you would a software product. eg: frequent and numbered releases, same rigour as a product.
  • 4) Use the smallest team you possibly can
  • 4) Attach the domain problem first (or - work on your domain model before other parts of the app).

嗯嗯,看了真是大有同感啊 (其實都是讀他們的書,自然會同感啊 :-p )。第一條是使用多層次的架構。這一點我想只要寫過一段時間程式的人都會認同,沒有分層的程式真的很難寫,不好測,幾乎沒辦法維護。想想看一個 jsp 裡面夾 SQL 外加畫圖,還寫了 2000 行... 除了 orz 還是 OTZ。對了,有點要澄清的是,分層式架構並非只限定在 Multi-tier 的架構,只要是複雜的需求、應用,就要考慮分層。

第二條是建立自動化的回覆測試。呵,測試的重要性自然不在話下,而重點更是擺在 automated, regression 兩字,這要用過之後才會有真正的體會啊。可惜台灣寫測試的不多,也不了解的測試帶來的生產力提升,開發人員也多視 Unit Test 為畏途。哎哎哎,我只能說開發人員你們浪費許多不必要時間,而老闆們花了不必要的錢。台灣的公司要導入 Test 真的很吃力啊。若有心導入的話,給個建議,不要專案中途開始寫測試,也不要後來補測試。這種 "測試" 法跟 XP 講的 Unit Test 有一段很大的距離呢,叫我寫這種測試我也會怕啊。它的差別就像... 打個比方,就像是不懂 java 的人還以為 java 和 javascript 這兩種是一樣的咧。要導入 Test,得先拿新的 project 來開刀,找幾個資深來試,重頭開始寫起,剛開始用生產力一定很低的,要有耐心。等過了一兩個月,開發人員若有所悟之後,才會真正發揮功能,而後再開始推廣到其他人、其他專案上。最後再回頭審視那些沒有寫測試的專案,就比較懂的該怎麼處理了。

第三點是比照做產品的心態來做 Application,也就是常更新並規畫版次,把它當做嚴謹的產品來做就是了。個人沒有參與過軟體產品的開發... 所以沒有什麼特別的感想。不過我對專案和同事的要求都蠻機車就是了 :-p

"要好好寫啊,要多考慮未來維護的問題,不要 method 隨便寫完就放著給他爛"

"喂喂喂,這裡怎麼沒寫 Test?沒寫 Test 還 commit 上去喔?快找個時間補上去,不然明天直接把你的 code 給殺了

...

以上純屬真實,好孩子不要學~~~

第四條是盡可能用最小的團隊。完全同意啊!!個人的經驗是六個人最多,不能再多了,再多只會變慢而已。專案初期就以最大六人為分組的依據,分好後就各自帶開,自己討論自己的。組跟組之間的溝通、介面的設計就讓較資深,或是 domain 比較厚的人來做。千萬不要開一個小時 + 十幾個人的會議啊!!不是一堆人發呆就是鬧意件不合,完全沒效果還倒扣咧

最後一點是先專注在 domain 上。這點個人的經驗就不大一樣了... 我通常會先把最不懂的部份先弄懂再說,不僅限於 domain。像是連接儀器,或是 web browser 一些特殊效果等等技術問題得先處理才行,如果技術做不到,則轉彎找其他的做法,然後才開始跟客戶探討較深入的 domain 問題。個人覺得 domain 是個很長久的東西(相信大家也是 :-),要學很久。而有時候也會遇到客戶沒有 domain 時 (因他也是第一次做.....),等於是要自己創造 domain 。這條路我才剛起步,不敢多言,但對 "先專注在 domain 上" 有個啟發:我們 (IT) 最終都是為了解決 domain 的問題、進而提升它的效率而存在的。所以心力和方向都要朝提升 domain 做最佳化,這才是 win-win 的目標。而不是一味地對 IT 技術做最佳化,整天搞 buzzword,那只是為 IT 而 IT,不斷地內秏,對誰都沒有好處。


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>