前言：
本人從事小微企業資訊化工作已經有10餘年了，自己的一個小工作室帶著如流水一樣的成員開發了一個又一個的專案。在十餘年的經歷中，我自行研發了一套基於ASP.NET的框架。這套框架從V1到V8體現的是我對軟體工程理解的加深，回顧過去，8個版本的框架可以看出我的技術學習走向，也能看出每套框架的設計空間大小，更能看出基於框架開發應用程式的簡單程度。那正好，我最近在研發V8的框架中，對這些內容也有了更深的思考和總結。寫出來與大家一起分享。
第一節：背景
本文所述的概念是有背景和使用範圍的。針對的是小工作室開發專案而不是製作產品。由於我所在的團隊屬於工作室性質，隊員的流動性極高。同時，我所涉及的專案大部分是短平快型別的，在統計我所有專案的開發時間後發現我花費時間最多的居然是升級框架，其次才是小型專案。那麼，在這個大前提下，我不方便使用自動化構建工具。因為眾所周知，自動化構建最麻煩的就是專案一開始的配置工作且這種東西學習成本非常高。如果是產品，那麼學習/配置一次你可以永久使用。而我的專案使用自動化構建就有雞肋（事實上我只對前端使用自動化構建）。
在此前提下，我的大部分專案都共用一個解決方案，我沒有人手單獨維護框架專案。只能是在不停的開發和使用過程中，更新專案框架（釋放設計空間）。直到有一天，這個框架的設計空間使用完畢，直接重構然後換下一個繼續。
其實，這種構架並不健康。我看了一下，好像也沒什麼人專門研究這種團隊。大部分人認為這種團隊其實是失敗的，活不久的，同時也是做不大的。不過呢，我見到的不少小型團隊都處於這個狀態下。畢竟，也不是所有人都能腦子一拍想出一個非常好的產品。哪怕有非常好的產品也不是所有人都能拿到投資。
於是，本文所對應的團隊背景一定要符合以下條件：
1、你所在的團隊開發的是一系列有共性的專案（比如都是CMS，或者都是MIS）；
2、你所在的團隊一定是小微團隊（5-10人），並且沒有足夠的人手維護框架；
3、你所在的團隊流動性很大，團隊成員的水平參差不齊，且學習成本高；
4、你的經費非常寶貴，也許你團隊的主要支出就是工資；
5、你在團隊中擁有一定的話語權。
第二節：什麼是設計空間
這是一個我自己對軟體架構穩定性的一個定義。設計空間指的在框架程式碼中，插入多少業務程式碼且不會影響框架的穩定性和複用性的空間。他有兩個子概念，在何處外掛程式碼不會影響框架的穩定性和複用性？插入什麼樣的程式碼不會影響穩定性和複用性？總的來說，外掛程式碼的位置數目和程式碼形式就是設計空間的大小評判標準。
我對“設計空間”的定義進行一個詳細的解釋：
1、新增的程式碼必須是面向業務的
軟體的程式碼大致可以分為兩大類：業務程式碼和框架程式碼。所謂框架程式碼，指的是可複用的程式碼，基本上在所有你所在的業務領域中都有的。比如，我專注於製作校企資訊化系統。那麼在這種系統中，無論哪個都會有：使用者，角色，許可權和組織機構。而無論哪個系統的使用者一定有ID，姓名，學/工號，使用者名稱和密碼。那麼這些類，這些欄位就是屬於框架程式碼，他們是可以複用的，而框架程式碼不會佔用設計空間。
業務程式碼指的是專注於某個具體業務的，比如在V3框架時代，我還是一個做學校網站的萌新。當時我開發了“某校網上展館v1.0”系統。該系統分屬於CMS系統，當時做的時候還是使用三層架構。在該系統中，擁有一個類“展板”。那麼對於這個類和我所在的業務領域中，除了這個專案，再其它任何專案中我都找不到需要使用這個類的地方。那麼這個類就使用了我V3框架的設計空間。
2、新增後的程式碼必須會影響架構的穩定性或複用性
由於是小型化團隊，你沒有可用的人手維護框架專案。所以，在這種情況下使用自研框架（不要問我為什麼不用成品框架，2010年我開始工作的時候，ASP.NET的框架簡直沒法看），為了保證程式碼的複用和更新，你唯一的作法就是把所有專案都引用同一個框架部分。比如，在我的V3版本框架中，6個專案都使用了同一個Model。我現在已經沒有那時候的設計工具了，直接截個圖給大家看看。
圖1 所有專案所共有的Context
在這種情況下，你每增加一個類（一張表）都會使用設計空間。因為除了框架中所需要的類，其它任何類你都無法複用。而小團隊有個非常麻煩的問題——人員流動性大，學習成本高。也就意味著，一個新人來到你的團隊很可能需要兩週甚至三週的學習。這種學習時間和過程，他們就會碰到一堆其實根本用不到的類。所以，在這種情況下，我認為這些類侵佔了框架的設計空間。
再舉個例子，比如V3框架的工作流模組，使用的還是WWF。在這裡，我寫了很多自定義的活動：
圖2 V3工作流模組中的某個活動
請注意，這些活動的複用性絕對是0。因為他們是針對業務開發的，只有在“某校實驗室管理系統”專案中，這些活動才有使用的可能。後來者不需要閱讀此模組，但需要學習模組中的一些寫法。於是他們的存在就非常尷尬，刪也不是，不刪也不是。他們也侵佔了設計空間。
除了這種情況，還有一些程式碼會影響架構的穩定性。這裡需要介紹一下，構架的穩定性和軟體的可靠性是不一樣的。架構的穩定性指的是需求的變更和程式碼的變更對軟體系統影響大小，這是一個經驗量。軟體的可靠性指的是在具體的使用環境中，軟體系統一段時間內的出錯次數（或者說魯棒性），這是可以量化的。本文討論的是穩定性。
這一次來到了V4框架，構架的背景是2015年，那時我對RBAC系統的理解還非常淺，並且完全不懂Claim-based的構架。在這種情況下，我們來看一下獲取使用者函式的實現：
圖3 影響穩定性的程式碼
觀察上述程式碼，可以看到user.IsInRole直接把具體需要的角色寫在了SecurityService的類裡。這是一個完全無法接受的行為，因為，根據統計數字顯示，我的框架獲取使用者的元件呼叫的就是本函式取資料，而這個元件每天需要被呼叫數萬次。而哪怕換了一個系統，取使用者還是這個函式，還是這套程式碼。那麼，換了一個系統還會有“教務處管理員”嗎？顯然，這是不可能的。再比如，哪天教務處要新增一個新的角色，比如“創新學分管理員”，對就是上述程式碼裡的OR後面的東西。那我需要修改所有受影響的程式碼，那這種構架就是不穩定的。而編寫這種程式碼，就是在釋放設計空間。
第三節：設計空間的意義和度量
設計空間是我評判一套框架好壞的重要指標，設計空間的意義在於我對系統可以做出多少破壞，也在於我可以對系統進行多少修改。設計空間大的系統，在面臨需求變更時，可以通過釋放一部分設計空間來換取最高效的修改速度。
而如何度量設計空間？我一般使用插入點的數目來定大小。我翻閱框架程式碼就會去理解哪些程式碼中是可以通過插入業務程式碼來實現最快速修改需求的目的。把這些數目加起來，就是我度量設計空間的方法。根據我本人的實踐而言，設計空間的大小不應該小於需求功能總數的1.5倍。比如V4框架的使用者模組設計空間在經過衡量以後就只有20左右。而開發一個使用者模組，我就說的簡單一點，使用者，角色，許可權和組織機構的CRUD就有16個。那麼在這種情況下，新來的需求雖然也可以通過本框架實現，但修改的時候就會感覺束手束腳，哪都不方便。
比如，還是上述例子。其實最早的函式（設計空間為2）是長這樣的：
這個函式的設計空間就很大（大小為2，基本就是我註釋的地方）。因為他完全是不基於業務的。也可以看到，當實際的需求來臨的時候（即只有“教務處管理員”等角色才可以根據學號的一部分找到使用者，而其它角色只能通過輸入完全的學/工號才能找到使用者），我可以通過釋放設計空間的形式，將上述程式碼快速複製一份並且變成圖3的樣式。這一修改可以在5分鐘內完成，10分鐘內部署，那客戶就會認為你的業務能力強，能夠快速按他們的要求修改系統。
所以，維持設計空間的最終目的是為了可以快速的按變更後的需求修改系統。設計空間的大小於與修改需求變更的時間成反比。
第四節：設計空間的釋放和侵佔
設計空間既然被定義出來，那一定就是為了被佔用的。所以，何時使用設計空間就是一個非常重要的事。我認為，在專案的開發和設計階段，使用設計空間就是一件非常不好的事。因為這時，明明可以通過對系統設計的修改而保住這些設計空間，甚至可以為將來的修改留下足夠的空間。所以，在這種情況下使用設計空間，我稱之為：侵佔。即，你本來可以不使用，但卻使用了將來的空間。
而在專案實際執行後，由於需求的變化你可能需要以最快的速度響應這些變化。這時，你就要根據實際需求釋放設計空間。比如，今天來了一個重要需求，領導要求你半天必須解決。這是，觀察需求一看之前留下了設計空間。那就可以通過直接釋放的形式使用這些空間來快速完成專案。
那麼，非常容易理解和想到的一點就是。當一個系統的設計空間被釋放的差不多時，也就是這個系統應當重構的時候。重構時，不光要把之前的設計空間還回去。還需要根據未來需求變化的可能和方向重新預留設計空間。
第五節：總結
設計空間的本質是擁抱變化，最終目的是快速修改變化的需求。他體現著開發者對需求未來變更可能性的掌握程度。一個好的設計者可以在看到需求時就想到未來可能發生的需求變化。而使用設計空間的本質是開發者考慮不周或者因為其它原因的妥協，還是圖3所示的例子，如果我當時就知道找使用者有可能按角色有不同的找法，那麼設計上直接給予許可權“按部分學/工號查詢使用者”，使用時，我只要配置哪個角色有此許可權即可（即，V5框架中就有）。那麼，當需求變更發生時，我就不需要使用設計空間。
需要知道一點，研發系統是有時間成本的。設計者哪怕在考慮到需求未來變更可能性的時候，也不可能將所有可能性都留下介面和設計（時間成本不接受，開發成本也不定接受）。所以，這時可以留下一個設計空間，在未來需求變更時，直接通過釋放設計空間的形式也能快速達成修改需求的目的。
諸位如果對這個有興趣的話，不妨可以留言討論。如果有興趣的人多的話，我接下來就再寫寫如何在“設計空間的預留和使用”。