2015/10/12

搞什麼,軟體架構師只要會畫圖嗎?

真的嗎?當一個軟體架構師,只要會畫畫方塊圖,把軟體元件用線連一連就好了嗎?如果有個人說他是在做架構師的工作,那麼他平常都在做什麼呢?Architect 在軟體公司,是個令人稱羨的工作,他在團隊中,代表有著累積出來的工作經驗,也有絕對的說話份量,但這一切都只是畫畫元件關係圖,就能夠表現出來的嗎?

軟體架構師在幹麻?

你是個軟件架構師嗎? 這篇文章對軟體架構提出了一些看法。

軟體架構可區分為五個部份:

  1. 管理非功能性需求
    設計架構必須要先知道系統的規模,使用的方式,使用的對象等等非功能性需求,才能根據這些需求,提出一個「適當」的軟體架構。

  2. 定義元件架構
    邏輯分割系統的功能模組,適當地區分這些模組的用途以及互通性,並在後面決定實作的方式以及負責的人選。

  3. 選擇實作的技術
    根據團隊成員的技術能力背景以及狀態,決定實作的技術,不同的專案時程,會有不同的忍受度,也間接決定,要讓哪些成員使用那一種技術實作,如果是短期要收到成果的專案,不用考慮太多,就直接選擇最熟悉的技術以及最熟悉的專案成員去實作。

  4. 評估架構
    架構中如果有一些技術瓶頸,需要預先測試用以判斷技術的可行性,這時候需要先做一些 prototype。要確認架構是否可行,必須搭配一些前期測試,先將專案的 critical path 實作出來,並以前期測試的方式,評估架構的可行性。

  5. 架構協作
    當專案成員對架構有任何問題時,或是不清楚如何串連整個系統元件時,必須進行進一步的釐清,確保所有成員都知道如何完成整個實作方案。

基本上我們可以把軟體架構師的工作內容,當作提出上面這五個部份的軟體架構計畫的內容,重點是計畫內容必須符合現實的需求,要確實可行而不是天馬行空的計畫方案。

提出「簡要抽象且可行」的實作方案

一般的計畫內容,文字部份比較容易被視為是填充版面的功能,最重要的是,每一個人在打開一份計畫文件後,第一直覺就會去看架構圖,看看計畫裡面這些圖表合不合理,所以,如果有著一些鉅細靡遺的圖表,就算搭配一些不知所云的文字描述,也足夠應付一個好的計畫文件。

其實就像是在做投影片一樣,寫一堆字倒不如畫出幾個示意圖來得簡單且清楚,要注意的是,元件的關係是不能隨便畫的,每一個元件跟連接線段的關係,都要有相當且充分的理由足以支撐這個概念。

軟體架構師重點是要提出一個「簡要抽象且可行」的實作方案,計畫方案中並沒有實作的細節,但架構師必須要知道每一個部份的設計,並能提出要這樣設計的理由。

軟體架構師 vs 專案經理 vs full-stack developer

軟體架構師的工作內容看起來其實也是什麼都要會,而且很接近專案經理的角色,軟體架構師跟專案經理的差別是:

  1. 專案經理貼近客戶,軟體架構師貼近開發團隊
    專案經理的工作大都在客戶端,產出的文件大都是客戶的需求下,所需要得到的專案文件,軟體架構師則是在開發團隊中的技術 leader,產出的文件是給團隊內部實作時的參考文件。

  2. 專案經理優先考量時程跟成本,軟體架構師優先考量符合需求
    專案經理受到客戶端的壓力,所有的工作以及行為,都是以時程跟成本為前提,但軟體架構師會在時程跟成本的條件下,更注意客戶端隱藏的需求項目,這些項目常會造成專案的隱藏成本增加。

  3. 專案經理接受最小範圍的實作方式,軟體架構師增加考量未來的擴充以及延伸
    專案經理為達到目的,可以接受開發團隊用最快的方式疊床架屋,軟體架構師會考量到未來的維護以及擴充性的問題,會要求團隊遵循「適當」的原則實作。

另外有個常常聽到的名詞「full-stack developer」,聽起來也是一種什麼都要會的工作項目。 What is a Full Stack developer? 針對這個名詞,提出一個定義:full-stack developer 是一個熟悉軟體開發各個層次的工程師,對所有軟體技術有高度的興趣,但不熟悉所有的技術細節。

Full-stack 的層次包含了下面這些 layers:

  1. Server, Network, and Hosting Environment.
  2. Data Modeling
  3. Business Logic
  4. API layer / Action Layer / MVC
  5. User Interface
  6. User Experience
  7. Understanding what the customer and the business need

看著看著,跟架構師對比一下,不就是軟體架構師也要會的東西嗎?軟體架構師跟full-stack developer的差別在哪裡?

  1. 軟體架構師在意技術的限制,full-stack developer 注意軟體技術的功能
    軟體架構師跟 full-stack developer 都需要了解各個層次的軟體技術,但架構師比較注意技術本身的質量以及限制,而full-stack developer因為喜歡嘗鮮,喜歡進行各種不同的嘗試。

  2. 軟體架構師比full-stack developer更能進行抽象思考
    軟體架構師必須要提出簡要的實作計畫,需要更多抽象思考的能力,而 full-stack developer 必須要能實際上使用、操作與轉寫程式。

如何承擔軟體架構的責任

軟體架構師要能夠以宏觀的眼光來看整個系統的架構,還要能夠隨時切換自己的角色,也就是說,我可以是 SA、SD,必要時也可以是 PG。軟體架構師必須從頂端來看整個系統的概況,同時又可以縮小到關注程式碼的運作。

架構師還是要會寫程式,為什麼呢?會寫程式,才能驗證架構的可行性。更重要的是,架構師是貼近開發團隊的工作,要提出一份「可行」的架構方案,得到開發團隊的認同,所以架構師說出來的話,要能禁得起考驗。

要能得到團隊的認同,並不是耍耍嘴皮子就可以了,架構師要有足夠的技術實力,講話才會有人理你,不然也是檯面上迎合,檯面下自由發揮。

專才 specialist 還是通才 generalist?

最後來個開放式的問題:軟體架構師是個專才還是通才?

或許換個問法,專才還是通才更適合扮演軟體架構師的角色?

References

Not an Expert in All Levels of Abstraction

The 「Software Engineer」 Mindset

Software Architect – A Role, Not a Job

The full stack developer is a myth

The Full Stack Developer

如何培養架構性思考 (談軟體架構師必經之路) - 投影片分享