軟體架構師養成秘笈（一）

圖片取自：http://www.zhougong.com/qita/73778.html

其實，我算鮮少談論這種比較不談程式碼 & 非技術性的議題，最近，常聽到周遭朋友在網路上談論 & 臉書 PO 文或是撰寫相關文章談論著架構師相關的議題，也有先前 MVP 的朋友們公司在找架構師，雖然一直都找不到 XD，但稱職的軟體架構師真的不好找。

我的工作經歷

而我從事相關的軟體開發工作已經有好長一段時間，從 1998 年畢業到現在，我也是從小 PG 開始，過程中經歷 SD、SA、RD、PM、Program Leader ，而最後又回到 SD 的角色、後來選上 MVP 後因緣際會地到了集英信誠擔任顧問角色一路到現在，現在除了協助客戶開發流程的導入外、我也協助軟體架構設計規劃，而因為我接觸的都是實際產業界的狀況，多半也是客戶實際面臨的棘手問題，所以不見得你可以直接套用你手中現有設計的軟體架構，因為有的客戶是現有系統有效能瓶頸希望你改善、有的是有套前人留下的架構但是不知如何團隊協作加速開發、有的是系統雜亂不堪+疊床架屋後遭遇嚴重 BUG 不知道該怎麼辦！所以，你沒有固定招式可以套用在所有的客戶上，你得因(人／客戶)而異的規劃全新的方式(當然都是自己的經驗加以融合後的結果)，所以每一次都需要一個完整的需求了解 => 現實情況拿捏 => 客戶環境 => 模擬情境 => 與客戶討論與改善方式建議 => 接著才是進行的方式、當然也有談不攏根本不會合作的，但這邊是說明客戶自己也想改善的，並且客戶採納我的建議的。

當然，這邊有點扯遠了，改天也許我可以寫一篇顧問的甘苦談，但此篇文章我先把重點先放在『軟體架構師』如何養成？我以自身的相關經驗來說明，先說明有些是我個人經歷，並不代表每個人都應該是如此，因為凡事沒有絕對的。

因為我前一份工作是系統設計師，專職便是軟體架構設計，當時便是公司內部主要 C# 與 ASP.NET MVC 相關課程的主要 Trainer 講師 + 同時也是幾個專案的負責人兼架構設計人員，也有寫作部落格習慣，也因此在當時因緣際會選上 Microsoft MVP，而後的顧問工作期間，也是幾個客戶的架構設計顧問，那麼，這邊我稍微的娓娓道來我這幾十年來、我自己的改變是什麼？

軟體架構師可以養成？

等等？軟體架構師可以養成？對了，我必須先說明清楚，架構師的養成沒有固定方式可以以依循，想要在這篇文章取得固定招式的可能要失望了，但.. 這是什麼意思？我舉個例子好了，我剛畢業的時候，在第一份工作就職期間，看到系統部使用 Delphi 替公司內部撰寫 ERP 系統，深深被 Delphi 那神奇的 IDE 工具與強大的 Object Pascal 所吸引，記得當時系統部解決了一個 Report 的問題，我當時不斷的詢問到底是如何解決的？回家後還去買了 Delphi 2.0 的書籍來看，我記得當時剛進入 Delphi 2.0 的時代，但當時還是有許多現有系統仍然使用 Delphi 1.0，我記得 Delphi 1.0 是 for Windows 3.1，它也是 Borland 針對 Windows 3.1 平台所推出的企業級 RAD 工具，與微軟當時自家的 VB5 相比更加 Powerful 也搶走不少原先在 VB5 的開發人員，因為 Delphi 使用的 Object Pascal 完全的支援物件導向，並不像 VB5 只支援部分的物件導向，因為 VB 撰寫的是基於 COM/ActiveX 的軟件架構，COM 的介面實作系統本來就不完全支援繼承，所以不具備完整的物件導向（下面簡稱 OO, Object Oriented 或 OOP, Object Oriented Programming）特性。

對了，另一個重點是，我第一次踏入軟體開發這個行業『完全思考當時市場有多少人用』、『我很單純的只是對【程式語言】有興趣而已』，也就是說我只是想要［寫程式］而已，就這麼簡單！其他的我沒想太多。

我常聽到有朋友在問進入此行業時要挑什麼語言入手？要挑什麼產業進入較好？說真的，如果你問我，如果你是新鮮人，現在的我還是會告訴你，如果你真的喜歡寫程式，那麼、都可以，因為什麼產業？什麼程式語言那都不是重點，重點還是在於你對於【程式語言】的熱衷程度，怎麼說呢？以我自己來說，我當時對於物件導向極感興趣，我不光是上班時再寫程式，連休假日的時候，我都在研究 OO 的內容，大約在 1999 年的時候，我就有撰寫部落格的習慣，因為我覺得將自身所學，撰寫成文能夠將所學真正消化吸收，是學好一樣東西最好的方式，且當作是個人筆記也不錯，於是當時創立了小毅的酷小站，只不過我真的開始撰寫與軟體技術相關的內容應該要從 2000 年開始，依稀記得在 2001 年左右，撰寫過一篇基於 Delphi Object Pascal 的 OO 的文章物件導向 OOP 基礎概論，當時我真的超級熱衷於 OOP 幾乎是廢寢忘食的在玩 OO 的東西。而 VB6 因為專案的關係而學習使用了兩年的時間（微軟在 2000 開始已經是 VB6 的天下了），我記得當時我也對 COM 非常感興趣，因為當時許多 Client-Server 的系統都正向著 Three-Tier 靠攏，正是 Windows DNA 分散式環境的萌芽期，而當時的分散式環境的主軸就是 DCOM, Distributed Component Object Model，因此我花了相當多的時間研究 DCOM 與 OLE Automation，當時也撰寫的篇文章 OLE Automation 應用，現在看還真是讓人懷念。

好～說了那麼多，現在在真的進入我要講的重點之一，一直到現在的顧問身涯，當時的語言基礎影響我很深，我曾接觸過 Java，但是我沒花多少時間大約兩個禮拜便稍稍上手開始撰寫基本系統，我也曾在從沒真的用過 Angular 2 的情況下，以我對於原生的 JavaScript/ES5 與 DOM 等概念，只花一個禮拜摸熟 Angular 2，還去客戶端執行教育訓練，我要說的是，其實我一開始根本沒挑市場最多人用的程式語言入手，我只是將基礎練得扎實 + 在專案中使用，我只憑著熟悉 OOP 領域的內容，我學習其他 OO 的程式語言都非常的快速，所以我後來也不擔心現在市場有多少人用，因為不管什麼語言，如果你的領域真的用的夠深你的 Pay 應該都不會太低，所以也不會有那種學什麼程式語言的 Pay 會比較高的問題會發生。

初期最少熟悉一種技術

我常常跟新進人員說，寫程式就是一個 Trouble-shooting 的過程，也就是你在撰寫程式的過程哩，其實有七 - 八成的時間是花在【解決問題】上，你自己遇到的問題你自己是否都能夠解決，這是一個重要參考指標，甚至可以說成你適不適合做這一行的參考指標，如果你要更進階，你得先做到自身無任何問題後，才能能力解決替別人解決問題，幾個例子：我現在工作在解決的問題都不是我的問題，都是客戶的問題，更不用說客戶問題千奇百怪，還不一定只有程式的問題。

先前，曾有學員問過我，要如何熟悉與精通多種技術，並做到『廣博』？他剛畢業不久，從事軟體開發相關工作大約一年多。而我告訴他，其實剛開始你根本不需要想如何廣博，你應該先『專精某種技術』即可，因為日子一長、經驗一多、做的專案越來越多、時間慢慢一拉長，自然而然就會做到『廣博』這件事情。

問題導向的學習方法