X24 程式寫作員的未來(2)──框架的使用

經過同領域的數次專案洗禮，很快就會明白只管達成功能的作法會造成許多不一致的災難，包括想改一個問題得調上百個程式或是改問題就像倒骨牌一樣改好了這邊卻壞了另一邊，這時會開始使用框架的設計（當然，也有加快開發速度的考量）。無論是使用其他公司提供的或者是自己設計的框架，都會在系統架構上定義一些規範作為開發所遵循的標準。



對建立執行架構的人來說，使用框架的設計可以將一些通用的執行必須功能包裝在裡頭；讓開發人員從必須從頭到尾瞭解執行原理，簡化為只要知道如何設定且實作交易之所需。在沒有使用框架的設計，開發人員必須自己弄懂底層後包裝為可用元件並測試之；使用框架可以簡化開發的工作，技術比較好的架構人員必須去瞭解框架的原理與細節，開發人員就根據架構人員所定義好的系統架構進行交易開發。如此一來開發人員所需的技術門檻將會大幅降低。



從上圖應可概略看出開發人員減少需要技術的困難部分，但相對地需要知道要如何去運用底層框架──不管是框架本來就提供的功能或是架構人員因應專案所作的設定。因此，架構人員除了去瞭解其他技術並運用之外，還應該提供足以讓開發人員活用系統架構的教學與說明，才能發揮團隊的戰力。曾看過有人將流行的技術組裝出一個執行平台後，僅教開發人員說怎麼做可以正常執行而不說明其他可能的變化，到最後變化出現時不是沒人可處理就是自己還得再回去調整。

只留下一堆設定檔與程式的話，除了少數條件好的開發人員外幾乎無力改變任何東西。有些架構人員會說當初他們也是自己慢慢摸索出來的，但在我看來其話中的含意是說“條件差的就不要浪費時間再看，條件好的就跟著在他們之前摔過的地方同樣再摔一次吧”。以這樣的心態建立系統架構的話，沒有辦法快速拉抬開發人員的經驗與實力，自己也會感覺他們怎麼這麼不中用。

註：通用的Class應依照先訂Interface再設計開發的方式，這裡不再詳述。目前偏重架構上的描述。軟體架構要設計到什麼程度？是某本書的第八章，8.2提到高來高去式架構設計的症狀還真是很貼近我的體驗。