工作筆記 - 實務上從髒扣到優化

前言

歷經從單純寫 jQuery 直接控制 DOM，寫起來真的爽，看見什麼就寫什麼，想到什麼就寫什麼。單一功能可能沒感覺，但整頁都是功能的時候，回過頭來整理就會很痛苦，拜框架所賜的關注點分離解決了這一大半的問題。

專案情境

目前當道前後端溝通使用的 Web API 實務經驗還不夠，只了解一點概念，但實務上有許多眉角要知道的地方，花了一點時間熟悉外，也因為基礎不夠好嘗了許多苦頭，每天對我來說都很戰兢，深怕技術力不夠就又要說再見了！

這次專案的 API 　資料類似下方格式：

select:[
{
title:'option_001',
id:'1',
code:'code_001'
},
{
title:'option_002',
id:'2',
code:'code_002'
},{
title:'option_noCode'
id:'3',
},
]

專案要求是，需要有一個 select 選單，看資料內容會有幾種情況：

1. 當 code 沒有值的時候，要出現沒有 code 的選項。
2. 當 code 是 code_001 的時候出現 code_001 的選項。
3. 或是 code_002 的時候出現 code_002 的選項。

因為我是用 VUE 開發，故下方寫法為 VUE 的寫法：

給予監聽事件

看到 select 事件當然要給予的是 change。

<select @change="disableApisFiltered"></select>

然後在 methods 的地方建立一個 disableApisFiltered 的方法，面對編輯器真的就知道自己能力實在有夠菜，我第一個想到的是使用 if 的判斷式來進行，所以變成下方程式碼：

前提說一下，因為已經先取得 API 了，所以這邊的 API 是在專案包裝過後的方法，這邊就不贅述。

disableApisFiltered(){
  return this.Api.filter((item) => {
    if (item.code === undefined) {
      return this.Api;
    } else if (item.code !== undefined) {
      return item.code === this.query.code ? true : false;
    } else if (item.code !== this.query.code) {
      return this.query.code;
    }
  });
}

說明：

1. 先把 API 透過 filter 方法篩選出資料。
2. 如果資料中的 code 是 undefined 時候，就回傳整個 API 資料。
3. 或是如果資料中的 code 不是 undefined 的時候，就回傳資料裡的 code 是不是跟 select 事件中的 code 相同。
4. 或是資料中的 code 不是跟 select 的 code 時，就回傳選單自己的值。

當下再看功能是可以如預期中一樣的呈現，但過兩天回頭要維護優化時，實在覺得看了難過。

難過的地方

會看到滿滿的 if 判斷，又一直看到相同的程式碼不斷的出現，可讀性又低，所以就嘗試優化了。

優化的過程

菜雞如我實在想不出什麼好思維，後來就請教前輩如果要優化該怎麼去想，他提醒我把剛剛的情境重新思考一遍，用另一種說法講出來。

先分析目前狀況：

1. 就是有值跟沒有值
2. 跟資料的值相同就顯示該選項，若不相同就傳整個 API 資料。

後來就換句話說：

1. 如果選項有值的時候，就去篩選資料，然後讓資料的 code 跟選單的值一樣。
2. 不然就回傳整個 API 資料。

所以程式碼就變成：

disableApisFiltered() {
  if (this.query.code) {
    return this.Api.filter((item) => {
      return item.code == this.query.code;
    });
  }
  return this.Apis;
}

結語

哇!

整個令人驚豔，果然經驗老到的前輩就是不一樣，透過實務經驗學到了寶貴的一課，希望透過這個觀念對於後續開發又更好的優化能力。

前輩說不用一開始就想要寫漂亮的程式碼，寫程式跟寫稿子一樣，先把思維寫下來，再慢慢整理成有條理的思維，也不要一開始想效能的事情，雖然前端工程師要注重效能，但更要確定功能正常運作，效能的考量是更進階的事情。

給自己做個紀錄，未來參考用。

六角學院