A Shell of a Problem 小節
在單機的世界,OS 的重點在簡化操作,讓大多數的人都可以用,特別是非 IT 人員(這是 MS 起家的訴求)。這是 GUI 的優點。換句話說,當僅維護單台機器,少數使用者時,適合不用背指令,直覺化操作避免錯誤的 GUI。
但網路連線後,多點,多類工作,多流程,多資料結構…無法用 GUI 串接,因為要自由組合異質資料結構,透過 UI 難以呈現。這反變成 GUI 介面的弱點,IT 管理者的痛。
在多台機器維護軟/硬體,為新使用者在多台機器設定不同服務的不同權限,在多機器做集中化安裝、部署、管理、監控、批次、稽核紀錄…等,需要自動化的 Script Shell,所以 PowerShell 是訴求 MIS 自動化。
以 API 來隔絕系統是好的,其實 Text based 作業系統(Unix/Linux)等於是以文件當 API,但這缺乏有效的資料結構,變成一切都序列化/反序列化,前一個指令將結果序列化成字串,下一個指令再反序列化成資料結構,在記憶體中處理完再交給下一個,形成 Pipe 串鍊,這對開發而言有利有弊。
如同整合資料系統時,傳遞資料是否要落地,落地等於是文件化交換,這也是優劣參半。而以 API 為組合單位的系統自動化,需要包裝這些 API 的 Shell,也就是物件導向式的 PowerShell。
Culture 小節(討論開發團隊的文化)
若每一件事都可以單元組合,也就是每個單元都具備自己的生命周期,從開發到遞交,也就會要 Unit Test。當組合越複雜時,測試涵蓋率越難提升,也就越需要 Unit Test。
但這是否跟規模有關,某個規模之下,交互作用沒有複雜到難以處理。雖然交互作用是相乘的,但個數不多,基數不大,也就不會難以處理,則專門的測試者執行測試是否比較有效率?
因為把測試的工作拉到開發者,也是開法者自己內部的單元複雜度提升,每個開發者都是一個單元,分析、設計、開發、測試、部署…等,也都是一個人內部的交錯複雜度。把複雜度放在哪,如同卸載負載,對整個團隊而言,應該都是動態的移動。換句話說,把小系統的測試工作分給每個開法者做,是否是小的系統要規劃 Load Balance,恐怕是殺雞牛刀。
當然,養成寫 Unit Test 的習慣又是另一個議題,與分工的關係不大了。
The .NET Framework Connection 小節
元件化(Component-based architecture)是軟體高唱學習硬體的主旋律,但硬體受限於搬動與組合原子,現今的 Services、Serverless function 似乎更標誌著資訊本身是電子的特徵 :)。但畢竟我們是原子本體,電子傳遞,虛/實混合,線上/下整合的時代,我們的 Framework 總是混著結構化/物件導向化/元件化/服務化。
Windows 小節
天高皇帝遠的另一種解釋,皇帝挺你也沒用 ^^