寫在前面

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

寫文章的道理其實跟開復盤會議一樣，通過思考和總結，我們可以將自己改變的更好。學習可以改變自己，而我們也正是為了改變而學習，寫文章也是一種學習的方式。

當然，由于文筆及文采的限制，寫的內容可能無法滿足所有人的需求，但是，這些內容中，只要能夠講清楚一件事，講清楚哪怕只有一個知識點，這件事或者這個知識點哪怕只有一個人認同，那么，寫這些東西就是有意義的。

Review的功能模塊

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

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

Reviewd的問題(收獲)

• 真需求 VS 偽需求

直屬領導上來就提了一個致命的問題：這個功能是誰在用？真的有必要做這個功能嗎？

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

當然，這里也不是說這個功能不好，這里反映出的問題是：在開發(fā)一個功能前，我們到底有沒有理解相應的需求？這個需求是個真需求，還是一個一個偽需求？。

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

• 數據格式

當某個功能后期可能會進行擴展時，比如一個用于枚舉的列表，后端返回的數據通常是一個數組。

對于這種可擴展的數據格式，我們需要而且必須和后端進行對齊，而且前端必須做相應的判空處理，永遠不要相信后端返回的數據都是靠的。

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

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

后端有可能告訴你，啊，我這個b只會有一條數據，當name是空字符串的時候就表示這b沒數據。

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

所以，有歧義的數據格式一定要跟后端對齊，同時前端一定要做相應的防御性措施，該判空的判空。

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

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

• 異步函數的定義

通常在請求接口的時候我們會使用函數的異步標識async來定義異步函數。但是有時候可能寫習慣了，在不需要做異步處理的地方也定義了異步函數，比如：

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

這時候就可能會出現意想不到的問題。

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

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

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

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

如果對有具體業(yè)務含義的變量定義的過于簡單，且還有沒相應的注釋，那么不經意之間我們就給自己和其他同事挖了一個坑。

• 運算符的使用

在用三元運算進行判斷時，我們通常這樣寫：

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

這個判斷我們可以用!!運算符進行優(yōu)化：

let hasGold = !!detail.target

當然，還有很多其他的運算符，比如?.、??。雙問號是null判斷運算符，作用和||雙豎線是一樣的。

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

左側為null 或者undefined時，右側就會生效。

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

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

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

try-catch的使用，個人理解的主要時用來防止一些外部的錯誤，比如：

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

有時候我們在定義變量或者函數的時候，可能會出現一些意想不到的問題，try-catch會提前將這些問題拋出來，避免產生更復雜的問題。

外部問題，可以理解為try{}花括號之外的問題。

最后

雖然這次CodeReview涉及的功能非常簡單，其中暴露出來的問題依然值得我們去仔細思考一下。

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

以上就是CodeReview常見的幾個問題梳理解決示例的詳細內容，更多關于CodeReview 問題梳理的資料請關注腳本之家其它相關文章！

最新評論