jim yeh on 六月 13th, 2007

本文係投稿於 CNet / ZDNet Taiwan 的文章初稿,未經 CNet 編輯,其內容可能會略有差異。

同人最近在向新同事介紹專案的軟體架構,說明架構的組成、運作過程及程式實作等觀點,希望讓新加入的成員對專案的技術面向有比較全面及完整的認識。在我簡報完畢後,新同事對這個用最新的設計觀念及最新的技術所建構出來的軟體架構充滿新鮮感,她問我:「這個架構都是你一個人設計的嗎?」,我回答說:「是呀」。當她用充滿敬佩的眼光看著我時,我告訴他:「但是這些都不是一天就設計出來的呀,成熟的架構其實是要靠時間來累積呀,所以架構的驗證很重要」。

後來,我想到一句話:「羅馬不是一天造成的」,可以用來描寫我在發展軟體架構上的感想;不過,最近考古學家發現,羅馬很有可能是一天造成的,我想那麼高的工作效率,除了帝王專制的力量之外,古羅馬人大概掌握了我們所不知道的關鍵能力。然而,開發軟體與建造城市終究不一樣,在軟體設計的領域上,獨裁政體會阻礙創新思考,掌握關鍵的技能也是無法速成的,因此,成熟的架構其實也不是一蹴可幾的呀。

同人有一個同學,我們在求學時代就一起研究電腦程式、畢業後還一起架設 BBS 及討論工作上的心得,每次和他討論到軟體設計的理念問題時,他總是認為軟體開發者必須優先思考營運的現實面,而不要太堅持設計理念。雖然我時常會笑他,他離開技術太久了,不過他卻是一直以技術人自居,當然我知道其實他會這樣想,是有他的理由的。以前在他的公司開始開發新產品的時候,他的開發團隊之成員們都有一個共識,就是希望能夠做到一次到位的設計-也就是不會因為需求改變而動到設計,其中有位開發者 X 君,他很喜歡在設計過程中加上許多大師的設計觀點;然而產品開發卻是有時程壓力的,X 君的做法卻造成了開發團隊的困擾,設計有彈性固然是不錯的想法,但沒有必要的複雜度,卻讓問題不斷叢生,時程數度延宕,我的同學已經受不了來自各方排山倒海而來的壓力了。

因此,後來當 X 君離開了我同學的公司後,同學就更堅信在營運現實的考量下,設計理念其實是不切實際的,堅持理想固然美好,但如果沒有在短時間把產品做出來,讓公司有現金流量進來,再多的設計想法都是空談,所以,他認為要等到公司獲利後,開發者再來堅持設計理念才是正確的做法。而 X 君呢?以他優異的開發能力,找到了一個待遇不錯的工作。不過,因為上次慘痛的經驗,他也不大敢再堅持設計理念了,反正工作待遇也不錯,雖然辛苦了些,但至少可以在此安身立命,只要他不再堅持設計的理想就好了。

在看了X君的故事後,我相信很多人都會這樣認為:理想夢想固然美好,但殘酷現實卻讓我們不得不放棄它們;然而,換個角度思考,我們明明知道這樣做行不通,偏偏還要這樣做,難道把過錯歸咎於環境或他人就可以解決問題嗎?身為軟體開發者,如果對工作現況不滿意,除了抱怨之外,其實還是可以試著改變的。理論是一回事,能否付諸行動又是一回事。如果沒有用具體行動來支持理念的落實,理論並無法創造任何價值,只有動手實踐,理論才會化成經驗知識形成智慧,幫我們解決問題,但沒有親身體驗是很難體會的。所以在工作上,等待機會,展現才能,就能創造自己正確的角色定位,然而重點是機會來臨時,你是否做好準備,所以,話不用說太多,用成果來說明一切,堅持設計理念與面對現實其實是可以不相違背的。

同人偶爾會與 X 君分享我的工作心得,他很羡慕我能夠堅持設計的理想,遵循好的設計原則及開發方法發展出軟體架構,像他就沒有這樣的機會。而和同學分享我的工作成果時,他則認為我堅持設計理念可以成功,是因為我們公司有足夠的資源可以讓我們玩,換成是小公司,就不會有這樣的成功條件。其實,我同學與 X 君都只看到結果,卻沒看到發展軟體架構的過程中,我們所遭遇到的困難。而這些困難中,尤以來自最高領導階層的阻力最難處理,然而,透過團隊通力的合作,用具體的概念驗證及技術驗證來取代理論上的辯解,讓他們對採用新穎的技術及前衛的設計能夠放心。

軟體架構設計重點並不在一次到位的空想,而是會隨著需求變化而逐步演進以適應變化,架構在逐步演進的過程中,是需要大家的回饋與溝通,所以軟體架構雖然是由一人所設計出來的,然而卻是大家共同努力的成果。

所以,對於同學認為「軟體開發者必須優先思考營運的現實面,而不要太堅持設計理念」的觀點,同人以為開發者最好不要以線性思考模式來看問題,現實當然不能忽略,但若因為營運考量而忽略設計甚至不去做設計,表面上軟體開發成本雖然降低了,但降低開發成本很容易就被競爭對手模仿,除了抵削低成本的優勢而減少獲利外,並且還會增加競爭壓力不斷地造成削價競爭的惡性循環。

因此,面對現實不代表不能堅持設計理念,而是在於開發過程中,是否有積極面對現實的態度,以漸進式的方式發展出可演化的設計,先用最簡單的方式來解決問題,當問題變複雜時,再針對需求的變化改善並演化設計,讓最適合的解法躍然成形,而不要想在一開始就找到最完美的設計手法,在設計上保持敏捷的態度,面對問題專注在方法論的採用、調適與熟練三部曲。設計其實不須急著一次到位,以軟體開發的過程來看,終究羅馬不是一天造成的呀。



     

7 Responses to “羅馬不是一天造成的”

  1. Brecht 說道:

    「最新的設計觀念及最新的技術所建構出來的軟體架構」,請問是什麼樣的觀念和技術呢?好奇中。

  2. jim yeh 說道:

    最新的設計觀念包括 Analysis Transaction Pattern, OOD principles, Loose Couple, POJO, IoC, AOP, SOA, Business Delegate Pattern.

    最新的技術包括 JSF, SpringFramework, Hibernate, XStream, FreeMarker, JAX-RPC, jXLS.

    這些在同人所任職的公司都是最創新的應用。

  3. andy lee 說道:

    專案的軟體架構

  4. [...] 舉個例子來說,架構設計必須包含架構的概念驗證(POC,Proof of Concept)。架構設計者不應該省略驗證架構的程式,卻期待程式實作者來幫他實現未經驗證的設計構想。他必須自己親自驗證架構,如此才能透過驗證,使自己設計的架構趨於成熟,而不致讓開發團隊在使用架構的過程中出現問題叢生的困擾。 [...]

  5. [...] 為什麼技術經理要攬那麼多的事情在身上,而不去把它們交給其他人來完成呢?主要的原因通常是技術經理擔心團隊成員沒有足夠的基本能力,不能把事情做好反而會讓他浪費更多的時間來處理爛攤子。除非技術經理能夠培養團隊成員的能力,讓他們也能夠操作他會的技術,這樣他才有可能抽身去做更有效益的事情。但問題通常是在團隊成員的素質參差不齊,要培養操作技術所需要的基本能力是有困難的,畢竟羅馬不是一天造成的。 [...]

  6. [...] XDite 用「理想狀況」來反駁用 TDD 來瞄準、射擊、修正後再射擊的觀念,他說很多時候, Team 裡面有開發者不能強迫導入 TDD 的環節,強行推動只是互相絆倒和拖垮彼此的時程,這是所謂的「現實狀況」。這麼說似乎是意味了 XP 敏捷方法的 TDD 實務無法在「現實狀況」實行,而是「理想狀況」。這種說法對同人其實並不陌生,就像我在〈羅馬不是一天造成的〉這篇文章所提到的情形: 同人偶爾會與 X 君分享我的工作心得,他很羡慕我能夠堅持設計的理想,遵循好的設計原則及開發方法發展出軟體架構,像他就沒有這樣的機會。而和同學分享我的工作成果時,他則認為我堅持設計理念可以成功,是因為我們公司有足夠的資源可以讓我們玩,換成是小公司,就不會有這樣的成功條件。 [...]

  7. [...] 其實同人很認同讓成員學習多重技能提昇團隊素質是很重要的一件事,過去我在為某個專案團隊導入 TDD、daily build、以及 formal inspection 等作法的時候也是希望成員可以透過這些活動來提升他們的技能。只是有時候團隊的成員從組織的四面八方而來,他們有不同背景、習慣和資質常會為成員學習成長帶來一些挑戰,還有最累人的是專案經理會給你一個什麼都不懂的人,要你讓他 on job training。本來同人有提供了一份考題,可以讓他找到能力符合我們團隊需要的人才,但結果他並沒有使用那份考題。於是苦了同人和其他幾位負責帶領新人的同事,雖然羅馬不是一天造成的,但它不代表成員不需任何基礎,最後我們沒有把那位新人培養起來,最後公司只好把他調到其它專案。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">