談軟體設計:尊重每一個使用者 - 依賴反轉


幾段隨筆,談 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 究竟是兩個差異化的產品。

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

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


延伸閱讀

站內資料

相關資料


Comments