幾段隨筆，談 IoC / DI 與管理的想法。

依賴反轉 與 組織管理

Note: 2019/03/02

依賴反轉 (Dependency Inversion, DI) 是軟體工程裡的一種原則，目的是解構兩個軟體元件之間的強關係、高耦合的現象，透過反轉的特性，讓高層次介面自行決定如何依賴其他元件，達到 控制反轉 (IoC, Inversion of Control) 的效果。

DI 最有名的說法：”Don’t call me, I’ll call you”

同樣的概念，應用在軟體，也可以應用在 #管理團隊 的協作，也就是把團隊之間依賴的特質，反轉回去。舉例來說，A 團隊執行任務，但依賴於 X 與 Y 團隊，B 團隊依賴於 Y 與 Z 團隊，A / B 兩團隊需要同時間交付任務，最後的 Battleneck 一定會出現在 Y 團隊，然後就會出現 Lock 現象。

執行的任務與需求，只要透過依賴反轉的方式，例如讓 Y 團隊開發工具 (SDK / CLI / API)，給 A / B 團隊使用，讓這兩個團隊自行決定如何使用，然後就會得到結果，而不需要過度依賴於 Y 團隊，影響專案進行，也影響團隊士氣。

而 A / B 兩團隊要使用 Y 團隊開發的工具，前提必須在這三個團隊之間定義 介面 (Interface)，也就是彼此協作的 協議 (Protocol)。透過這個協議，#解偶 任務執行過程中的 阻塞現象 (Blocking)，然後以 非同步方式 (Async) 執行任務，讓 A / B 之間不要因為排隊、或者強佔 Y 團隊的資源，造成 Lock 現象。

Interface 與 Protocol 的定義是團隊跟團隊協作的必要，而這是管理者的工作，因為只有在資訊條件充裕的狀況之下，方能定義出這些東西。

這些概念，在計算機科學裡，都有對應的模型與機制 (I/O Models)，而在人與人之間的協作，其實也有一模一樣的現象。相關參閱 Study Notes - I/O Models。

控制反轉 (IoC)

Note: 2019/06/05

一段埋藏在心裡很久的設計想法，有天 在公車上把他敲下來，主要是 IoC (Inversion of Control) 的設計概念。

從 IAM Policy 的設計，談依賴反轉

很多年前第一次看到 AWS IAM 的 Policy，第一時間想得到就是：

權限管制與政策的設計就是這樣。

AWS IAM 權限的設計概念包含：

1. 權限使用者 (User, Group, Role)
2. 執行動作（Action, 動詞）
3. 管控的資源 (Resource)

所以這三個加起來，組成 Policy，IAM 透過 JSON 表示這樣的概念，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:Describe*",
                "cloudwatch:Describe*",
                "cloudwatch:Get*",
                "cloudwatch:List*",
                "elasticloadbalancing:Describe*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

這樣的設計，透過 JSON 資料結構，讓管理權限者可以自行決定如何管理。

很久以前設計權限系統，大多以 AOP 概念設計，但是那僅只於功能上的實踐方法，透過 AOP 的關注點分離，讓商業邏輯與授權邏輯更加拆分，但並沒有考慮企業用戶實際上在使用時，如何有個方法可以設計自己的『授權邏輯』，然後定義屬於自己的授權政策。

後來跟同事無意聊天中，把這個設計概念抄過來，也就是授權邏輯程式碼的想法 (Policy as Code）。企業用戶要的是高度彈性與高度客製，要設計可以滿足客戶的業務功能，其核心概念就是『依賴反轉』，或者『反轉依賴』。

用依賴反轉，讓使用者自行設計需求

『依賴反轉』的概念就是：

你要什麼，我讓你自己決定。

用程式碼系統概念來說：

SDK / CLI 這些東西就是依賴反轉的最佳範例

他把所有的參數都寫在文件裡，讓使用者自行決定如合透過參數達到自己想要的功能。這種概念這幾年發揮到極致的 宣告式設計 (Declarative)（K8s deployment yaml，Terraform 都是），透過這種『反轉』的概念讓客戶決定自己要什麼，可以設計屬於自己的政策。

AWS IAM Policy 的設計概念也是一樣，這樣的概念能滿足企業用戶必須要的彈性與複雜度。另一個類似的概念就是 Redmine 的 Filter 設計，其核心概念已是依賴反轉。使用者只要能夠定義出來想要看什麼，只要能夠指定條件，就能設計各種面向的查詢與視角。

『依賴反轉』的設計看似好，但實際上它也依賴於使用者自身的能力，換言之，使用者對於自己的『需求』要有一定程度的自知之明。這概念如同 Unix / Linux 的概念一樣：

尊重每一個使用者，假設你知道自己要什麼樣。

『依賴反轉』提供高度客製化與彈性機制給使用者，而『反轉依賴』則提供最佳實踐給使用者，也就是很多人想要找的 best practice。這場種概念實際上就說是某種『專家系統』。以前我常舉的例子就是 微軟的 Powerpoint，他的設計從一開使只有提供一堆功能，到後來提供了很多常用的樣板，甚至是很專業，且是針對性的『主題』，例如針對行銷的樣板，針對產品發表會的。。。等，而一些行銷公司也提供了更專業的樣板販售，這背後販售的是『經驗』。

產品的設計，初期都會是單一個功能，然後是功能的集合，最後是把實踐放入，但是依照不同的使用對象，會提供不同的視角與產品線。頻果的音樂製作產品 GrageBand 和 Logic Pro 究竟是兩個差異化的產品。

你在開發產品，但也在用別人的產品，你感覺的到他們的差異？

— 未完 (公車開太快，到公司了)

延伸閱讀

站內資料

• Study Notes - I/O Models

相關資料

• Linux的最高指导原则：尊重每一个使用者