前言：
本人從事小微企業資訊化作業已經有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框架中就有），那么，當需求變更發生時，我就不需要使用設計空間，
需要知道一點，研發系統是有時間成本的，設計者哪怕在考慮到需求未來變更可能性的時候，也不可能將所有可能性都留下介面和設計（時間成本不接受，開發成本也不定接受），所以，這時可以留下一個設計空間，在未來需求變更時，直接通過釋放設計空間的形式也能快速達成修改需求的目的，
諸位如果對這個有興趣的話，不妨可以留言討論，如果有興趣的人多的話，我接下來就再寫寫如何在“設計空間的預留和使用”，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1031.html
標籤：架構設計
上一篇：DoD企業DevSecOps架構
下一篇：為什么TCP的初始序列號是隨機的