ch2

Ch2. 兩個價值維度

  每個軟體系統都為利益相關者(stakeholders)提供兩種不同的價值維度:行為(behavior)結構(structure)。軟體開發人員負責確保這兩種價值保持高水準。不幸的是,他們往往只關注其中一個而忽略另一個,更不幸的是,他們往往只關注較低價值的那一個,最終使軟體失去價值。


行為

  歉體的第一個價值來自於行為。程式設計師被聘請來使機器以一種能為利益相關者帶來獲利或節省成本的方式運作。我們透過協助利益相關者制定功能規格或者需求文件,然後編寫程式碼,使利益相關者的機器滿足這些需求。當機器違反這些要求時,程式設計師便開始除錯以修復這些問題。


結構

  軟體的第二個價值來自於結構,軟體之所以為「軟」體,是因為它被創造出來是為了方便改變機器的行為。為了實現其目的,軟體必須要有足夠的彈性,易於修改。當利益相關者對某項功能改變主意時,這種改變應該要是可以簡單且容易進行的。進行這種改變的困難程度應該只與改變的範圍成比例,而不是與改變的形式成比例。

  然正是範圍和形狀之間的差異常常推動軟體開發成本的增長。這就是為什麼成本與所需求的變更規模不成比例。這也是為什麼開發前期比開發後期便宜得多的原因。

  從利益相關者的角度來看,他們只是提供了一系列大致相似範圍的變更。從開發者的角度來看,利益相關者給予他們一系列拼圖碎片,他們必須將其放入日益複雜的拼圖中。每個新的要求都比上一個更難擬合,因為系統的形狀與要求的形狀不匹配。

  我在這裡以一種非傳統的方式使用「形狀」這個詞,但我認為隱喻很貼切。軟體開發人員常常感覺自己被迫將方形木塊塞進圓洞中。

  問題當然在於系統的架構。如果這個架構偏好某種形式,那麼新功能愈來愈難以適應這種結構。因此,架構應該盡可能地不受形式的限制。


更大的價值

  行為與架構,何者提供更大的價值?對軟體系統來說,它的功能更重要,還是易於修改更重要?

  如果你問企業經理,他們通常會說軟體系統的工作更重要。開發人員通常也會贊同。但這是錯誤的態度,我們可以用簡單的邏輯工具來證明它是錯誤的,那就是檢查極端情況。

  如果你有一個完美運作但無法更改的程式,那麼當需求改變時它將無法運作,意謂著這個程式將變得沒有用處;然而一個不起作用但容易修改的程式,那麼我們可以透過簡單的修改使其運作起來,並在需求變化時保持運作,因此這個程式將持續保持有用。

  也許這個論點對有些人來說不那麼具有說服力,畢竟沒有什麼程式是真的不能改變的。但是,有些系統在實際上是幾乎不可能改變的,因為改變的成本大過於了改變的好處。許多系統在某些功能或配置上達到了這一點。

  如果你問企業經理們是否希望能夠進行變更,他們當然會說是,但可能會在回答中指出目前的功能比任何後續的靈活性更重要。相反地,如果企業經理們向你提出變更要求,而你估計的成本過高而無法負擔,他們很可能會對你允許系統達到變更變得不切實際的程度感到憤怒。


艾森豪威爾矩陣

  下圖為艾森豪威爾(Dwight D. Eisenhower)總統的重要性(importance)與緊迫性(urgency)的矩陣,艾森豪是這麼說的:

我有兩種問題,一種是緊急的,一種是重要的。緊急的問題並不重要,而重要的問題從不緊急。

img2_1

  軟體的第一個價值 - 行為,是緊迫但並非總是特別重要。
  軟體的第二個價值 - 架構,重要但從不特別緊迫。
  當然,有些事情既緊急又重要,或有些事情既不緊急又不重要。故最終,我們可以將這四種問題安排成優先順序:

  1. 緊急且重要
  2. 不緊急但重要
  3. 緊急但不重要
  4. 不緊急也不重要
      需要注意的是,程式碼的架構位於前兩個位置,而程式碼的行為則佔據第一與第三的位置。商業經理和開發人員常犯的錯誤是將第三位的事項提升至第一位。換句話說,他們未能將那些緊急但不重要的功能與真正緊急且重要的功能區分開來。這種失誤導致忽視系統的重要架構,而偏好系統中不重要的功能。
      軟體開發人員面臨的困境是,商業經理無法評估架構的重要性。這就是軟體開發人員被聘用的原因。因此,軟體開發團隊有責任強調架構的重要性,而不是功能的緊迫性。

為架構而戰

  履行這個責任意味著投入一場戰鬥,或者也許更好的詞是「奮鬥」。坦白說,這些事情總是這樣做的方式。開發團隊必須為他們認為對公司最好的事情而奮鬥,管理團隊、市場團隊、銷售團隊和運營團隊也是如此。這總是一場奮鬥。

  有效的軟體開發團隊會毫不畏懼地與其他利益相關者平起平坐地爭論。請記住,作為一名軟體開發者,您也是一個利益相關者。您需要保護您所需的軟體。這是您的角色和責任的一部分,也是您被雇用的重要原因之一。

  如果你是一位軟體架構師,這個挑戰對你來說尤其重要。軟體架構師根據他們的工作描述,更關注系統的結構而非其特性和功能。架構師創建一個架構,使得這些特性和功能能夠容易地開發、修改和擴展。

  只要記住:如果架構放在最後,那麼系統的開發成本將會愈來愈高,最終對系統的某個部分或整個系統的變更幾乎變得不可能。如果這種情況發生,那意味著軟體開發團隊沒有為他們知道的必要事項進行足夠的努力。