重點摘要#
- 不要從象牙塔中頒布決策，讓團隊實際嘗試多種方案
- 運用精實開發的「最後負責時刻（Last Responsible Moment）」原則延遲決策
- 嘗試多種方案比預先做決定需要更多努力，但往往是最不昂貴的選擇
- 架構師的角色是協調決策過程，而不是獨自做出所有決定
詳細內容#
建立應用程式需要做許多決策，有些涉及選擇框架或函式庫，有些圍繞特定設計模式的使用。無論哪種情況，決策的責任通常落在團隊的架構師身上。刻板印象中的架構師會收集所有可用的資訊，思考一段時間，最後從象牙塔中頒布解決方案讓開發者去實作。但不出意料，有更好的方式。
最後負責時刻#
Mary 和 Tom Poppendieck 在精實開發的工作中描述了一種決策技術：延遲承諾直到最後負責時刻。也就是說，如果團隊不做決定，決定就會替他們做出（即不作為會導致不可逆的結果）。
延遲決策是明智的，因為越晚做決定，可用於做決定的資訊就越多。但更多的資訊不等於足夠的資訊，而且最好的決策往往是事後才知道的。
實際做法#
好的架構師應該持續關注即將需要做出的決策。只要團隊有足夠的人數且實踐集體程式碼所有權，架構師就可以：
- 當接近決策點時，讓幾個開發者各自提出解決方案並實作一段時間
- 在最後負責時刻到來時，團隊聚在一起評估不同方案的優缺點
- 通常，有了事後之明，最佳方案對每個人都是顯而易見的
這種方法適用於小決策和大決策。無論是決定是否使用 Spring 提供的 Hibernate 模板，還是選擇哪個 JavaScript 框架，都可以用這種方式。
為什麼嘗試多種方案值得#
嘗試多種方案確實需要更多的前期努力，但預先做一個決定往往會導致後來被認為是次優的方案，讓架構師陷入兩難：
- 回退當前實作 – 浪費之前的努力
- 忍受次優方案 – 同樣浪費努力
更糟的是，如果沒有探索替代方案，團隊中可能沒有人認識到所選方案不是最佳的。在這種情況下，努力被浪費了，卻連意識到浪費的機會都沒有。
畢竟，嘗試多種方案可能是最不昂貴的選擇。架構師不需要自己做決定，而是協調決策過程。
— By Erik Doernenburg