重點摘要#

• 架構師習慣性地立刻進入解題模式，但有時最好的解法是不解題
• 很多軟體問題只是看起來像問題，實際上只是症狀
• 在解決問題之前，先問自己：「如果這個問題不存在，架構會長什麼樣？」
• 質疑問題本身，而非被動接受需求

詳細內容#

架構師過去多半是開發者，開發者因解決程式問題而獲得獎勵。這些通常是小型的、精巧的演算法問題。這種對解題的迷戀會讓我們養成壞習慣——隨著時間推移，我們開始不加思索地接受問題，不問這個問題是否有意義、是否有用、是否符合道德。

有時候最佳解法是不解題#

很多軟體問題其實不需要被解決。它們只是看起來像問題，因為我們只看到了症狀。

• 考慮託管記憶體的例子：託管平台上的開發者並沒有「解決」記憶體問題——他們的解決方案讓這個問題根本不存在
• 考慮複雜的建置流程：與其解決建置問題，不如退一步思考——這其實是自動化和可攜性的問題，可能有工具可以完全消除它

我們不應該成為需求的被動接收器，像 Pez 糖果機一樣開心地分發我們最聰明的解決方案。

改變問題而非解決問題#

• 像使用長焦鏡頭一樣，放大和縮小來確保問題被正確框架
• 不要僅僅接受被給予的問題，要質疑我們接收到的東西
• 問自己：「如果我根本沒有這個問題，架構會長什麼樣？」
• 看看是否能改變問題本身，這往往能帶來更優雅、更可持續的解決方案

我們必須打破對「問題」的沉迷。在考慮答案之前，先想想如果這個問題不存在，世界會是什麼樣子。

— By Eben Hewitt