過程抽象

  寫代碼寫不動了,沒有那麼精細。退遠一點發現什麼都可以操控,只不過代碼邏輯間距變得很大。倒是更容易從全局看到局部,容易全局掌控。

  看一些寫代碼的討論,怎麼設計一個代碼分類,也就是代碼優化。

  最開始帶有類的編程考慮了這些事,把一個事物的各種描述和與它相關的處理方法都放到類裏。後來對一個web服務,寫程序的時候還考慮分成幾層來處理。哪個和用戶交互,哪個用來處理交互數據,哪個用來處理保存。把相應的功能朝某一個層來分。實際編碼的時候似乎並沒有這些考慮,在哪個地方最容易達成目的一般就寫在哪裏。

  這些歸類到層裏或者歸類到一個類裏,或者從代碼編排角度,這些層或者類的編寫方式可以有統一的規則,可以用來集成化、自動化開發。首先是第一步的歸類。

  並不侷限於類或者是層。也並不是在主要考慮把相關的功能聚合。是把這件事抽象成 程序和業務都能理解的處理步驟。 兩表相關聯,一個主表放着主要信息,一個從表放着一些不常用的輔助信息。當數據量越來越大,從程序角度來看,查一條數據就要翻閱整個從表,它倆的距離顯得越來越遠。從業務角度看,一個表內的數據有固定的用途。數據產生之後備份給不同的“部門”,每個部門需要的數據並不一樣。部門之間的數據很少同步。如果輔助信息放得特別遠,業務上也是需要單獨存放,用到的時候進行整理查閱,這樣就可以做從表關聯;如果輔助信息放得比較近,和主要信息放在一起共同使用,可以考慮直接放在一個表;如果主要信息是全部信息的一個特殊摘要,供給特定的部門使用,那它會有特定的方式和主要信息表做對接,更新程度也隨業務。

  業務到程序的抽象裏,找到哪些是最基本的信息,哪些是朝外的分搭。一個功能入口獲取的信息,相對於集體功能來說,是否可以作爲主表,或者可以以怎樣的方式搭建到主表上。主表又是怎麼被各個功能入口共同抽象出來,出現怎樣的(多個主表)內部層疊和交互關係。業務有一條清晰的線,這些線從功能進入,經過內部處理,形成整體過程。最開始實現功能,從基本需求起手設計相應字段,模擬拼合出一個整體實現過程。從這個臨時搭建的構想中,抽象出基本信息們和它們之間的交互。事件產生信息,分發到不同的部門,每個部門做自己特有的處理。

  第二步的歸類,也是同時進行的集成。

  對錶的操縱經歷一些步驟,取出數據放到相應的載體裏,進行處理並放回去。對控表的編碼有繁複的操作規範。取了表的數據放到方便使用的載體裏,也有相應的交流規則。整理業務的時候需要和這些規則靈活打交道。控表和便捷的載體在業務驅動下也相互制約。可以有統一的規範和通用的功能集合來封裝這些處理。

  當底層封裝過多偏向於sql的靈活生成,就偏向了sql的思維。有單獨的層面來封裝這些思維,會顯得上級邏輯步驟清晰。同時也會增加開發步驟。把相似的封裝做統一,自動生成相關代碼。

  這樣會減少精細部分的處理,可以從遠處操控。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章