架構師的選擇（覺悟）

原文連結：アーキテクトの選択（あるいは覚悟）

架構師的工作大部分時間都是在“做選擇”，這些選擇都是在一切發生之前所做出的，因此，一旦決定就不能更改了。

架構師所要選擇的是靜態的結構。方案一旦確定，就開始轉入退化過程。隨著時間的推移，系統的適應性會變差，對做出的決定進行修改往往要付出巨大的代價。

當然，專案經理對於進度計劃以及專案人員體制等方面的安排也屬於“事先選擇”。但是，這些選擇物件都屬於動態的過程。

動態的過程能夠隨著時間的推移適應其過程中出現的變化。包括敏捷等迭代式過程在內的開發過程，它們都推薦在開發過程中設立短期目標並根據實際作業情況做出調整。這是非常有效的方法。動態過程承認事先選擇中所發生的過失和偏差，且允許在事情發生之後做出改變。

有這麼一說：“Good managers do things right （優秀的管理者會做正確的事）”，專案經理所做的是把握事先選擇（計劃）和事後情況（實際）兩者之間的偏差，針對這些偏差對各種各樣的引數做出調整，將專案的發展方向始終沿著預定的軌道不斷進行修正。

然而，架構師的選擇卻是靜態的結構，敏捷的推進方式無法適用於這些靜態結構。

對於靜態結構而言，PO（Proof of concept/概念驗證）或是建立原型等“基於嘗試進行評價”的方法才是有效的。PO或原型等手段能夠降低風險，促成事先選擇，儘管如此，要讓選擇後的結果能夠適應事後的變化，這些方法仍然無能為力。

那麼，在這種情況下，架構師該如何做出選擇呢？

《軟體架構師應該知道的97件事》 中有篇文章：“24：重視不確定性 ”。

Confronted with two options, most people think that the most important thing to do is to make a choice between them. In design (software or otherwise), it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions. If you hardwire the first thing that comes to mind you're more likely to be stuck with it, so that incidental decisions become significant and the softness of the software is reduced.

當眼前出現兩個選項的時候，基本上任何人都會將選擇哪個作為最重要的事情去考慮。但是，在設計（軟體也不例外）中卻不是這樣。出現兩個選項的情況就是一種訊號，告訴你應該考慮該設計中所潛藏著的不確定性。

這一篇的作者Kevlin提到“在無法做出選擇時，要先停一停，退回去想想”。雖然這一點非常重要，但是在專案中，無論如何，讓別人停下等是不行的。就這麼等著，直到某一天做出選擇，進度上就難以保證了。

正因為如此，為了做出“必須這麼做才行”的決定，架構師要盡其所能地做到眼前所能做的一切，這一點就顯得格外重要了。

對於不同的選擇項，真正讓你無從選擇的原因是因為你無法確定判斷的基準。因此，問題的重點在於尋找判斷基準。

優秀的架構師總是能夠縮小“判斷”其本身對整個過程的影響。不管選擇哪種架構，多少都是帶著自信去選擇的。但是，僅僅這樣是無法得到“必須這麼做才行”的理由的。

也就是說，要做出判斷，不能僅憑眼前的基準，而是一定要找到某些能夠起到決定性作用的引數。這些引數應該兼顧對時間和空間上的考慮。

1年後會怎麼樣？2年後呢？3年呢？

程式設計師的觀點是什麼？PM的觀點是什麼？使用者的觀點是什麼？運維人員的觀點是什麼？

帶著這些問題去考慮，擴充利益相關人（stakeholder）的觀點，尋找用於判斷的基準。單憑想象是不夠的，所以親自去了解一下各方的意見吧。這些利益相關人自身的行事原理和依據是什麼？確立一個能提煉出判斷基準的行動方針，去尋找答案吧！

這樣，才能得到“必須這麼做才行”的理由。

倘若不論怎麼努力都無法得到“必須這麼做才行”的理由，你一定會意識到其中所存在的不足。 這樣就無法為這個選擇而負責，或直面未來會產生的風險。

也許你會做出的選擇並不正確。但是，一定要有“必須這麼做才行”的絕對自信。為了做出“必須這麼做才行的決定”而不斷努力，最後選擇了與自己的直覺最接近的方案，要堅定這樣的想法。

如果沒有這樣的覺悟，是無法說服自己做出“必須這麼做才行”的抉擇的。不論專案的規模是大是小，架構方面的決定都將影響到與專案有關的很多人。架構師應該始終牢記這一點。

權力並不是事先給予你的，而是隨著責任意識越來越強，權力會越來越大。架構師有了這種意識，無論面對誰，都能胸有成竹地回答：“這是正確的選擇/這樣做沒錯的。”

未來總是不確定的。但是，我們只能在現有的選項中進行取捨。為了做出“必須這麼做才行”的抉擇，要對戰略方針進行推敲，而這不正是被稱為“架構師”的這群人們其工作的本質嗎？

譯註

1. 本文作者鈴木雄介是一名IT架構師，同時也是日語版《軟體架構師應該知道的97件事（ソフトウェアアーキテクトが知るべき97のこと）》的譯者。