handlerOper(operInfo, node) {
  const graphInst = this.graphInst
  this.operateNodes = isUndefined(node) ? graphInst.getSelectedNodes() : [node]
      ......
}

由上面的代碼，今天我的同事問了我一個(gè)問題，“這里你非得用lodash的isUndefined的嗎？”為什么不把

isUndefined(node)

換成

node ?  [node] : graphInst.getSelectedNodes() 

或者

!node ?  graphInst.getSelectedNodes()  :  [node] 

我答，“我想更確定的表達(dá)什么情況下會(huì)執(zhí)行為‘true’的情況，什么情況會(huì)執(zhí)行‘false’的情況”。
他問，“你不就是要表達(dá)node存在與不存在時(shí)的邏輯嗎？我那種也行啊”
我答，“不存在就是用undefined來表達(dá)嗎，我這樣不很清楚嗎”

后來同事非常不情愿的結(jié)束了對(duì)話，當(dāng)然我也沒有讓他認(rèn)可。

能有這個(gè)認(rèn)識(shí)是在之前的創(chuàng)業(yè)公司的前輩告訴我，避免使用隱式類型轉(zhuǎn)換，盡量不要用，等于與不等的判斷也要盡量用!==和 ===，當(dāng)時(shí)的我并沒有因?yàn)殡[式轉(zhuǎn)換而踩過什么坑，但是他們是有過的，但我認(rèn)可這一點(diǎn)的原因主要是來源于這樣帶來的可讀性。

邊寫邊來分析一下同事的question，他的為什么會(huì)知道我要表達(dá)的是存在與不存在？而不是“為空字符串與不為空字符串”，“為零不為零”，“為空數(shù)組不為空數(shù)組”，“為空對(duì)象不為空對(duì)象”？
他能這么認(rèn)定，你們也許會(huì)說是對(duì)業(yè)務(wù)上下文理解。是的，但如果是對(duì)于維護(hù)代碼的新同事那是不是會(huì)有以上的疑問呢，按照他覺得的寫法。

同事還說，如果node是null或者其他不符合要求的node走到后面的邏輯，后面的處理就會(huì)報(bào)錯(cuò)了。當(dāng)時(shí)我并沒有回答他這個(gè)問題，現(xiàn)在想來，不符合的node格式在這里不是我需要cover的，而是使用node的地方需要cover的，我這里只是判斷是否有node傳入。

有時(shí)代碼可讀性就像潤(rùn)物的春雨一樣無聲，只有你讀過好的代碼，你才能知道什么是壞代碼的味道。有人說讀不懂代碼也許不是別人寫得不好，而是你能力不夠，但是我認(rèn)為，能夠讓別人花10秒鐘讀懂的代碼為什么要讓別人花10分鐘去理解上下文。

Whatever，每個(gè)人都有每個(gè)人寫代碼的風(fēng)格，然而喜歡和誰一起寫代碼就體現(xiàn)大家的favor。