兩種價值觀的故事
行為 / 架構
每個軟體系統都會為利益相關者提供兩種不同價值
-
行為 (behavior)
利用
功能規格 (functional specification)或需求文件 (requirements document)來達到這一點，然後實作程式碼，並且除錯。可悲的是：許多程式設計師認為這是們的全部工作。
-
結構 (structure)
軟體 (software -> soft + ware) 必須是軟的，他可以輕易地改變機器行為的一種方式。當利益相關者改變他的們想法時，應該要能簡單輕易做到。改變的難度應該與改變的範圍成正比，而不是與改變的形狀 (shape) 成正比。
這裡用了非常規的描述「形狀(shape)」，開發人員常常覺得自己被迫將「方釘」塞入「圓孔」中。
這是系統架構問題。架構越喜歡一個形狀，新的功能就越難以適應這種架構，因此架構對於形狀應該是不可知的，這樣才實用。
`這章節算是我第二次看，但我還是難以想像 shape 想要代表的是什麼？如果以 abstract interface 的概念去想，架構是一個介面，而 shape 是實作嗎？🤔
「架構越喜歡一個形狀」我想應該是指架構不要依賴某種實作吧…`
而開發人員有責任確保他們都保持在高價值，但…QQ
更高的價值
功能還是架構？哪個能提供更高的價值？兩個極端的狀況：
-
如果您給我一個完美的程式，但不可能修改，那麼當需求改變時，他就不能工作了，而我也將無法其工作。所以這個程式將變得毫無用處。
-
如果您給我的程式不能工作但亦於更改，那麼我可以使其工作，並隨著需求的變化而繼續工作。因此該程式將持續是有用的
實際上程式都可以改變，之所以「不可能改變」是因為改變成本超過了改變的利益。只是往往業務經理通常會覺得目前功能比起靈活度重要。
但之後的變更，往往只能把變動成本估計高得難以置信...然後業務經理就生氣了 QQ
Eisenhower 矩陣
我有兩類問題，緊急和重要。緊急的不重要，重要的不緊急。 (Dwight D. Eisenhower 總統 1954)
- 行為 - 是迫切的，但是並不總是特別重要
- 架構 - 是重要的，但從不特別迫切
最終可以安排順序：
- 迫切且重要
- 不迫切但重要
- 迫切但不重要
- 不迫切也不重要
程式碼的架構 (重要的東西) 位於前兩位，而行為只佔據了第一和第三
軟體開發人員的困境是業務經理沒有能力去評估架構的重要性。「而這就是軟體開發人員該去做的」
為架構而戰
履行這個責任意味著參與戰鬥。作為一名軟體開發人員，你就是一個利益相關者。有效率的團隊正為這個問題而奮鬥。他們毫不掩飾且平等地與所有其他利益相關者爭吵。
軟體架構師更側重於系統的結構而不是其特性和功能。架構師建立了一個架構，使得這些特性和功能易於開發、修改且輕鬆擴展。
這點也還在努力學習，回想自己的工作，往往太過於站在產品的角度去思考，反而沒去堅持該堅持的。大概能理解作者想說的事是，一個目標，需要有不同的角度去拉扯，但看過一些 MVP 或是精實創業的書，常常會說到，如果一開始產品方向就錯誤，其實「架構」再好也沒用。🤔這裡我也沒什麼定論，只覺得這個是勝者為王，敗者為寇的事情ＸＤ，不過身為想要成為架構師的我，或許該重新來堅持必要的東西。
