對複雜業務組件在實際開發過程當中被調用的反思

寫這篇文章的初衷是爲了記錄我在修復項目中一個複雜業務組件中的bug而引發其餘依賴這個組件的功能沒法使用的過程當中，對使用、維護複雜業務組件的一些思考

原文地址

Bug發生緣由

我所在的項目組中, 有一個相似樹狀文件管理的需求

對於這樣的需求，當時我設計一個基礎的UI組件treeListView用來實現基礎的樹狀UI， 同時在其基礎上實現了explorer業務組件來實現具體的業務邏輯。

因爲是樹狀的視圖，因此在當時設計數據結構時也採用樹做爲數據結構。爲了可以方便的查找樹中的數據，我按照系統的文件管理給全部的數據添加了一個path屬性。

可是在實現的時候沒有考慮到同級目錄下面可能同時存在同名的文件夾和文件這種狀況，假設文件夾folder下面同時存在名爲file的文件和文件夾，這個時候會形成它們的路徑相同，在查找的時候沒法區分這兩個數據。修復的方法是在文件夾的路徑後面增長/。

這樣修復後，因爲在咱們的項目中有許多的地方直接使用path來來作判讀，例若有的地方直接分割path來獲取當前數據的名稱或者其父元素的名稱（雖然有更好的方式獲取這些數據，可是開發過程當中可能爲了省事直接這樣獲取），或者在新建文件、文件夾時本身手動的拼寫path。

當我按照上面的方式修復bug時，就必須同時修改這個依賴path的函數操做，當項目中的代碼太多時就可能出現遺漏的狀況，給代碼的維護帶來很大的困擾。

爲何會出現這麼多的問題?

問題出現了以後就應該去反思爲何形成如今這樣的局面。誠然有一部分的緣由是咱們在開發過程當中常常會圖方便而隨意的使用數據，可是根本的緣由是在對一個複雜的業務組件調用過程當中，沒有一個方便、有效的操做形成的。換句話說就是對於組件依賴的數據沒有一個有效的操做形成的。

組件的正確依賴於數據的正確，而在開發的過程當中不一樣的開發人員有着不一樣的風格的數據處理方式。 一旦數據結構出現了錯誤或者發生了修改，就會致使組件出現意想不到問題。

如何解決這樣的問題?

對於業務組件, 咱們是能夠總結出對這個業務組件的調用的使用狀況，例如本文中的explorer組件主要有如下幾種狀況:

1. 新建文件夾、文件
2. 刪除文件夾、文件
3. 修改文件夾、文件
4. 根據路徑查找文件夾、文件
5. 根據路徑查找父文件夾

對於這些操做，在組件的編寫過程當中咱們能夠同時編寫對應的輔助函數，

如explorer組件我就編寫下面的輔助函數

return {
  // 修改屬性操做
  modify: modify,
  // 重命名操做
  rename: rename,
  // 新建操做
  create: create,
  // 複製操做
  copy: copy,
  // 移動操做
  move: move,
  // 刪除操做
  remove: remove,

  // 搜索樹中符合要求的數據
  searchTree: searchTree,
  // 根據路徑返回在樹種的索引
  searchByPath: searchByPath,
  // 根據路徑獲取數據
  getDataByPath: getDataByPath,
  // 根據路徑獲取父目錄的數據
  getParentDataByPath: getParentDataByPath,
  // 根據路徑獲取父目錄路徑
  getParentPath: getParentPath
  // 初始化數據中的path
  addSourcePath: addSourcePath,
  
  // 判斷是否存在同名數據(用於新建時同名判斷)
  hasSameName: hasSameName
};

這樣對於調用者來講，只要使用組件提供的輔助函數就能夠方便的使用組件；對於組件的維護者來講，只要保證輔助函數的正確性，就能夠保證組件在被調用的過程的正確，方便組件的維護。

總的來講，就是在編寫這樣複雜的業務組件，咱們應該同時編寫相關的輔助函數來方便組件的調用者來使用。而咱們在開發中也應當避免寫出上文中那樣對數據直接進行操做的代碼，這會致使業務的正確依賴於組件的內部數據相耦合，使組件難以維護。