羅馬不是一天造成的

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

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

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

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

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

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

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

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

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

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

Please follow and like us: