0%

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

sort

前言

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

專案情境

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
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 資料。

所以程式碼就變成:

1
2
3
4
5
6
7
8
disableApisFiltered() {
if (this.query.code) {
return this.Api.filter((item) => {
return item.code == this.query.code;
});
}
return this.Apis;
}

結語

哇!

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

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

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

六角學院