寫在前面

文章的主要作用是幫助自己進(jìn)行思考和總結(jié)，比如我們可能都遭遇過(guò)功能上線后出現(xiàn)了一些不可預(yù)知的bug，我們對(duì)這些bug進(jìn)行處理，完善之后，項(xiàng)目負(fù)責(zé)人可能會(huì)叫上這個(gè)功能的主要幾個(gè)開發(fā)人員做一次復(fù)盤會(huì)議，大家一起討論出現(xiàn)問(wèn)題的原因，然后定制對(duì)應(yīng)的方案，防止類似的情況再次出現(xiàn)。

寫文章的道理其實(shí)跟開復(fù)盤會(huì)議一樣，通過(guò)思考和總結(jié)，我們可以將自己改變的更好。學(xué)習(xí)可以改變自己，而我們也正是為了改變而學(xué)習(xí)，寫文章也是一種學(xué)習(xí)的方式。

當(dāng)然，由于文筆及文采的限制，寫的內(nèi)容可能無(wú)法滿足所有人的需求，但是，這些內(nèi)容中，只要能夠講清楚一件事，講清楚哪怕只有一個(gè)知識(shí)點(diǎn)，這件事或者這個(gè)知識(shí)點(diǎn)哪怕只有一個(gè)人認(rèn)同，那么，寫這些東西就是有意義的。

Review的功能模塊

這次CodeReview涉及的功能是數(shù)據(jù)的推理訓(xùn)練模塊，具體的需求是開發(fā)人員在錄入數(shù)據(jù)時(shí)，有兩種格式：yaml和json，有些人對(duì)yaml的數(shù)據(jù)格式不太清楚，所以需要有一個(gè)地方能夠支持yaml語(yǔ)法的配置，同時(shí)支持yaml和json之前的互相轉(zhuǎn)化，即：輸入yaml后，突然發(fā)現(xiàn)其實(shí)需要的是json，那么可以直接轉(zhuǎn)成json格式傳給后端，反之亦然。

yaml和json之前相互轉(zhuǎn)化的功能，npm上有相應(yīng)的包，有興趣的可以了解一下，這里就不再敘述了。

Reviewd的問(wèn)題(收獲)

• 真需求 VS 偽需求

直屬領(lǐng)導(dǎo)上來(lái)就提了一個(gè)致命的問(wèn)題：這個(gè)功能是誰(shuí)在用？真的有必要做這個(gè)功能嗎？

作為開發(fā)人員，假如我們不熟悉yaml的語(yǔ)法格式，我們可以快速的去學(xué)習(xí)一下，那么就沒(méi)有必要去浪費(fèi)人力和時(shí)間去開發(fā)這個(gè)功能，把時(shí)間用來(lái)開發(fā)更重要的功能豈不是更好？

當(dāng)然，這里也不是說(shuō)這個(gè)功能不好，這里反映出的問(wèn)題是：在開發(fā)一個(gè)功能前，我們到底有沒(méi)有理解相應(yīng)的需求？這個(gè)需求是個(gè)真需求，還是一個(gè)一個(gè)偽需求？。

這個(gè)問(wèn)題在開發(fā)前是要確認(rèn)清楚的。

• 數(shù)據(jù)格式

當(dāng)某個(gè)功能后期可能會(huì)進(jìn)行擴(kuò)展時(shí)，比如一個(gè)用于枚舉的列表，后端返回的數(shù)據(jù)通常是一個(gè)數(shù)組。

對(duì)于這種可擴(kuò)展的數(shù)據(jù)格式，我們需要而且必須和后端進(jìn)行對(duì)齊，而且前端必須做相應(yīng)的判空處理，永遠(yuǎn)不要相信后端返回的數(shù)據(jù)都是靠的。

比如下面兩種格式，后端有可能會(huì)告訴你，它們都表示空數(shù)組。

var a = []
var b = [{name:''}]

后端有可能告訴你，啊，我這個(gè)b只會(huì)有一條數(shù)據(jù)，當(dāng)name是空字符串的時(shí)候就表示這b沒(méi)數(shù)據(jù)。

但是，a和b從根本上就代表了兩種不同的含義。

所以，有歧義的數(shù)據(jù)格式一定要跟后端對(duì)齊，同時(shí)前端一定要做相應(yīng)的防御性措施，該判空的判空。

• 還是需要注意ts的類型定義

函數(shù)必須要有自己的返回值類型，函數(shù)參數(shù)也必須有相應(yīng)的參數(shù)類型。凡是ts無(wú)法進(jìn)行推斷的地方，ts默認(rèn)會(huì)推斷為any類型，那么我們使用ts進(jìn)行開發(fā)的意義又在哪里呢？

• 異步函數(shù)的定義

通常在請(qǐng)求接口的時(shí)候我們會(huì)使用函數(shù)的異步標(biāo)識(shí)async來(lái)定義異步函數(shù)。但是有時(shí)候可能寫習(xí)慣了，在不需要做異步處理的地方也定義了異步函數(shù)，比如：

const print = async () => {
    console.log('print')
}

這時(shí)候就可能會(huì)出現(xiàn)意想不到的問(wèn)題。

• 該有注釋的地方一定要有注釋

定義的變量有歧義的，有一定的業(yè)務(wù)含義的地方，注釋一定要清楚明了，比如：

if(dataDetail.target === 'pc'){
    // do something
}

pc如果有非常具體的業(yè)務(wù)含義，那么它表示的是personal computer 還是process center，或者是其他含義呢？

如果對(duì)有具體業(yè)務(wù)含義的變量定義的過(guò)于簡(jiǎn)單，且還有沒(méi)相應(yīng)的注釋，那么不經(jīng)意之間我們就給自己和其他同事挖了一個(gè)坑。

• 運(yùn)算符的使用

在用三元運(yùn)算進(jìn)行判斷時(shí)，我們通常這樣寫：

let hasGold = detail.target ===''?false:true

這個(gè)判斷我們可以用!!運(yùn)算符進(jìn)行優(yōu)化：

let hasGold = !!detail.target

當(dāng)然，還有很多其他的運(yùn)算符，比如?.、??。雙問(wèn)號(hào)是null判斷運(yùn)算符，作用和||雙豎線是一樣的。

const headerText = response.settings.headerText || 'Hello, world!';
const headerText = response.settings.headerText ?? 'Hello, world!';

左側(cè)為null 或者undefined時(shí)，右側(cè)就會(huì)生效。

• 代碼外部注意try/catch的處理，防止有其他的異常情況

我們通常在寫代碼的時(shí)候，尤其是寫頁(yè)面交互相關(guān)的事件時(shí)，一般不怎么考慮使用try-catch做處理。

但是，頁(yè)面上觸發(fā)事件，用戶手動(dòng)觸發(fā)的交互，我們有必要做一些防御性的措施，加入try-catch的處理，防止意想不到的問(wèn)題出現(xiàn)。

try-catch的使用，個(gè)人理解的主要時(shí)用來(lái)防止一些外部的錯(cuò)誤，比如：

try {
  console.log(a)
} catch (error) {
  console.error(error);
  // VM654:4 ReferenceError: a is not defined
  //  at <anonymous>:2:15
}

有時(shí)候我們?cè)诙x變量或者函數(shù)的時(shí)候，可能會(huì)出現(xiàn)一些意想不到的問(wèn)題，try-catch會(huì)提前將這些問(wèn)題拋出來(lái)，避免產(chǎn)生更復(fù)雜的問(wèn)題。

外部問(wèn)題，可以理解為try{}花括號(hào)之外的問(wèn)題。

最后

雖然這次CodeReview涉及的功能非常簡(jiǎn)單，其中暴露出來(lái)的問(wèn)題依然值得我們?nèi)プ屑?xì)思考一下。

盡管我們從事開發(fā)工作已經(jīng)很有經(jīng)驗(yàn)了，依然有很多地方值得去思考、去提升。

以上就是CodeReview常見的幾個(gè)問(wèn)題梳理解決示例的詳細(xì)內(nèi)容，更多關(guān)于CodeReview 問(wèn)題梳理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論