1，不理清楚業(yè)務(wù)邏輯，判斷亂用
? ? ? ?舉個(gè)栗子，有代碼如下：
? ? ? ? ? ? if (d.Status === 'Created') {
? ? ? ? ? ? ? ? if (d.isEdit === 'Y') {
? ? ? ? ? ? ? ? ? ? ? ? xx.displayName = '草稿'；
? ? ? ? ? ? ? ? } else if (d.isEdit === 'N') {
? ? ? ? ? ? ? ? ? ? ? ? ?xx.displayName = '草稿'；
? ? ? ? ? ? ? ? }
? ? ? ? ? ? } else {
?????????????????????xx.displayName = '已提交'；
? ? ? ? ? ? }
? ? ? ? 且不說(shuō)是否真的有關(guān)于isEdit的判斷（經(jīng)確認(rèn)，該字段就Y和N兩種值，不可能出現(xiàn)null或者空字符串），就算有，那也該找相關(guān)人員做進(jìn)一步的確認(rèn)，因?yàn)樯鲜雠袛鄬儆跓o(wú)效且浪費(fèi)資源的代碼，并且還有增加運(yùn)維工作量（需要梳理和確認(rèn)相關(guān)業(yè)務(wù)邏輯）和被誤改的風(fēng)險(xiǎn)；
? ? ? ? 所以，上述教訓(xùn)是，如果一個(gè)業(yè)務(wù)邏輯需要大量的if判斷，那么大量的if判斷應(yīng)該是以捋清楚業(yè)務(wù)邏輯為前提和目的，實(shí)際提交代碼應(yīng)該是完全理清業(yè)務(wù)邏輯的基礎(chǔ)上經(jīng)過(guò)完善的代碼，而非類(lèi)似上述代碼。
? ? ? ? 同時(shí)，如果一個(gè)業(yè)務(wù)邏輯需要大量的if判斷，不管能否精簡(jiǎn)（也即是相關(guān)判斷整合），都應(yīng)該注釋相關(guān)的業(yè)務(wù)邏輯（大致描述下即可）和關(guān)于該段代碼的思考（這段很重要，因?yàn)榻?jīng)過(guò)整合的業(yè)務(wù)邏輯有時(shí)候會(huì)很繞，這有助于運(yùn)維快速定位問(wèn)題，也會(huì)減少后續(xù)迭代或維護(hù)過(guò)程中對(duì)代碼的誤改風(fēng)險(xiǎn)）；
2，頁(yè)面加載不加loading
? ? ? ? 其實(shí)，在網(wǎng)絡(luò)情況不好的情況下（這種情況很常見(jiàn)，考慮到用戶(hù)基數(shù)，基本上等于一定出現(xiàn)）頁(yè)面加載會(huì)很慢，此時(shí)，加loading的目的是：
? ? ? ? ? ? 2.1，一方面是告訴用戶(hù)，操作已生效，當(dāng)前處于加載階段，使其不用太過(guò)著急；
? ? ? ? ? ? 2.2，另一方面限制用戶(hù)進(jìn)行誤操作，例如多頁(yè)簽頁(yè)面，一個(gè)頁(yè)面本來(lái)就沒(méi)加載完成，結(jié)果用戶(hù)還可以在加載期間切換頁(yè)簽觸發(fā)新的請(qǐng)求，結(jié)果就很可能是用戶(hù)覺(jué)得：這應(yīng)用，加載不出來(lái)了，還一點(diǎn)反應(yīng)都沒(méi)有，這是我機(jī)子的問(wèn)題，還是這個(gè)應(yīng)用的問(wèn)題？增加用戶(hù)的焦慮，不僅僅是體驗(yàn)不友好的問(wèn)題，還會(huì)增加與用戶(hù)溝通的難度（人在生氣的情況下很難溝通的）
3，狀態(tài)維護(hù)在本頁(yè)面內(nèi)
? ? ? ? 這其實(shí)是個(gè)需要斟酌的問(wèn)題，關(guān)鍵點(diǎn)在于該狀態(tài)在切換頁(yè)面后再返回的時(shí)候，還需不需要原狀態(tài)?
? ? ? ? 如果需要在返回時(shí)，維持原狀態(tài)的話(huà)，需要考慮如何緩存的問(wèn)題；基于Vue的開(kāi)發(fā)一般會(huì)在路由配置文件router.js里配置keep-alive進(jìn)行頁(yè)面級(jí)緩存，該方案在大部分情況下是可行的（只是需要了解頁(yè)面緩存之后，生命周期的變化，比較推薦的是BeforeRouteEnter和Be...Leave這兩個(gè)路由鉤子）
? ? ? ? 上述之所以說(shuō)大部分情況下，是因?yàn)槲⑿艃?nèi)置瀏覽器內(nèi)核對(duì)于keep-alive的緩存好像有問(wèn)題，例如本人最近碰到的一個(gè)情況：一個(gè)列表頁(yè)面有3個(gè)頁(yè)簽，其中兩個(gè)有按鈕，剩下一個(gè)沒(méi)按鈕（解釋下，有按鈕代表有詳情頁(yè)，沒(méi)按鈕代表沒(méi)詳情頁(yè)）；此時(shí)查看中間頁(yè)簽列表的詳情頁(yè)后，點(diǎn)擊微信下方的返回按鈕（微信不知道哪一次更新后，在頁(yè)面下方放了兩個(gè)按鈕，一個(gè)左箭頭代表回退，一個(gè)右箭頭代表前進(jìn)）回退到列表頁(yè)時(shí)，頁(yè)簽倒是正常顯示在了第二個(gè)頁(yè)簽，只是按鈕沒(méi)了。。。？？？
? ? ? ??所以，上述教訓(xùn)是：自己寫(xiě)的代碼，需要去看一下效果，一旦方案不兼容，就需要斟酌一下優(yōu)化的方式（例如本例中，考慮將狀態(tài)保存在vuex中，通過(guò)computed讀取數(shù)據(jù)的方式）
4，胡亂開(kāi)啟監(jiān)聽(tīng)
? ? ? ? 這個(gè)問(wèn)題出現(xiàn)的場(chǎng)景是在Vue中的watch事件定義中（但其實(shí)，該現(xiàn)象放之其他框架也是一樣的道理）
? ? ? ? 言歸正傳，有個(gè)需求，需要把頁(yè)面內(nèi)的搜索框優(yōu)化一下，改成實(shí)時(shí)查詢(xún)，即我輸入什么，馬上查詢(xún)，不再需要點(diǎn)一下搜索按鈕才開(kāi)始查詢(xún)；
? ? ? ? ?然后靈魂操作開(kāi)始了：1，首先在data里定義一個(gè)變量，跟輸入框綁定；2，然后在watch里監(jiān)聽(tīng)該變量，觸發(fā)查詢(xún)函數(shù)；
? ? ? ? ?其實(shí)上述操作倒也不是不行，畢竟我有時(shí)候也會(huì)給輸入框綁定一個(gè)@Input事件；但好歹加個(gè)防抖/節(jié)流處理呀，限制一下查詢(xún)頻率。（講真，這也是http1.1優(yōu)化了1.0時(shí)期的一個(gè)請(qǐng)求只能使用一條連接，不然這么頻繁而大量的請(qǐng)求，光是tcp三次握手和四次揮手就足以卡死了，都等不到響應(yīng)返回~）
? ? ? ? ?然后說(shuō)說(shuō)我的考慮吧：用戶(hù)之所以有這個(gè)需求，大致上應(yīng)該是因?yàn)閼械妙l繁點(diǎn)擊搜索按鈕；但事實(shí)上，用戶(hù)也不可能真的要求每輸入一個(gè)字符就查一次，所以基于這個(gè)考慮，大致上我們是可以考慮限制查詢(xún)頻率的；那么除了上述的防抖/節(jié)流限制查詢(xún)頻率，也可以考慮使用失焦函數(shù)（即Blur），在失焦的時(shí)候（一般是用戶(hù)點(diǎn)擊完成，關(guān)閉軟鍵盤(pán)的時(shí)候；PC端的話(huà)一般是用戶(hù)點(diǎn)擊非輸入框區(qū)域即可失焦）才進(jìn)行查詢(xún)操作；
? ? ? ? ? ?當(dāng)然，在不考慮需要進(jìn)行其他操作的前提下（例如查詢(xún)之前或之后保存當(dāng)前的查詢(xún)關(guān)鍵字，然后每次搜索的時(shí)候展示關(guān)鍵字列表等邏輯），考慮到用戶(hù)體驗(yàn)友好性，加了限制的Input事件（或者上述提到的watch監(jiān)控，實(shí)際上Input也是利用監(jiān)聽(tīng)機(jī)制）體驗(yàn)感會(huì)更好一點(diǎn)。
5，代碼封裝的可行性與必要性
? ? ? ? ? 一般而言，從組件化的思路來(lái)看，組件化一般服務(wù)于代碼復(fù)用的場(chǎng)景；這就涉及一個(gè)復(fù)雜而尷尬的問(wèn)題：如果多個(gè)頁(yè)面叫代碼復(fù)用的話(huà)，那這個(gè)多是從數(shù)字幾開(kāi)始算的呢？2？還是3？還是更大的數(shù)字？
? ? ? ? ?就我個(gè)人的理解，如果是大的項(xiàng)目，可以在一開(kāi)始就約定好；如果是小的項(xiàng)目，在保證文件順序一目了然的情況下（我的意思是，復(fù)用性很小的組件就盡量不要丟到components目錄了），可以?huà)侀_(kāi)上述多的限制（原因是，基本上后來(lái)人總會(huì)因?yàn)楦鞣N各樣的原因，例如思維方式不一樣，或者接受到的知識(shí)體系不盡相同，而對(duì)前人的代碼產(chǎn)生各種嫌棄。那我的想法是，做好當(dāng)前階段的事情，該注釋注釋?zhuān)摲庋b封裝。）
? ? ? ? 以下具體解釋下上述文字：
? ? ? ? ? ? 1）注釋的必要性：我在第一點(diǎn)已經(jīng)說(shuō)明了
? ? ? ? ? ? 2）封裝的必要性：
????????????????????一來(lái)，代碼封裝到一個(gè)整體的塊或者文件中，相關(guān)的狀態(tài)變量和函數(shù)一目了然，大大減少了后來(lái)者梳理相關(guān)流程時(shí)（如果他需要修改或優(yōu)化該處的邏輯時(shí)），來(lái)回查找相關(guān)函數(shù)或變量的工作量；
????????????????????二來(lái)，大大減少被誤修改的風(fēng)險(xiǎn)，功能相對(duì)簡(jiǎn)單的頁(yè)面還好說(shuō)，頗為復(fù)雜的頁(yè)面（一般PC端很常見(jiàn)，因?yàn)轫?yè)面寬度足夠，各種表格，各種頁(yè)簽，還穿插判斷）的情況下，大量代碼交叉在一塊，就很要親命了！此時(shí)，如果沒(méi)有進(jìn)行代碼拆分相關(guān)的工作，后期迭代或運(yùn)維過(guò)程中，巨量增加梳理工作量的同時(shí)，誤修改的情況發(fā)生也是不足為奇的。
? ? ? ? ? ? ?3）封裝的可行性：適度為準(zhǔn)，不太建議從走極端跑到右極端（即我覺(jué)得啥都可以封裝一下，一個(gè)頁(yè)面出現(xiàn)十來(lái)個(gè)子組件）的情況。
? ? ? ? ? ? ?4）封裝的時(shí)機(jī)：
? ? ? ? ? ? ? ? ? ? ? ?4.1），肯定是該邏輯復(fù)用性很強(qiáng)咯，基本上大部分頁(yè)面都會(huì)用到；
? ? ? ? ? ? ? ? ? ? ? ?4.2），相關(guān)邏輯復(fù)用性不那么強(qiáng)（例如，只有那么一兩個(gè)頁(yè)面用到），那就要考慮頁(yè)面體量復(fù)不復(fù)雜，以及該段邏輯復(fù)不復(fù)雜：
????????????????????????????????????a）考慮封裝的情況有該段邏輯復(fù)雜，而且代碼量在適中以上（比如涵蓋5~6個(gè)方法，十幾個(gè)變量）；
????????????????????????????????????b）不考慮封裝的情況有：該段邏輯不復(fù)雜，或者邏輯復(fù)雜的情況下，頁(yè)面體量不大（或者干脆就是個(gè)展示型頁(yè)面）；
? ? ? ? ? ? ? 5）以上論述及建議僅供參考，切不可生搬硬套，一切以代碼健壯性，以及減輕迭代和運(yùn)維工作為前提。
6，this暫存變量多種定義
? ? 6.1，為什么要暫存this對(duì)象：
????????????簡(jiǎn)單來(lái)說(shuō)，就是this指針會(huì)在調(diào)用的過(guò)程中發(fā)生改變，
????????????可以參考：https://www.cnblogs.com/lovellll/p/10225272.html
? ? 6.2，暫存亂象：
? ? ? ? ? ? 維護(hù)過(guò)一個(gè)“歷史悠久”的項(xiàng)目就會(huì)發(fā)現(xiàn)，關(guān)于this對(duì)象暫存對(duì)象的變量定義可謂是千奇百怪，比如：
? ? ? ? ? ? ? ? const? ?_this? =? this;
? ? ? ? ? ? ????const? ?_that =? this;
? ? ? ? ? ????? const? vm? =? this;
? ? ? ? ? ? ????...
? ? ? ? ? ? 其實(shí)，變量名取什么是開(kāi)發(fā)者個(gè)人的自由，但從代碼規(guī)范的角度，以及代碼健壯性和可維護(hù)性來(lái)說(shuō)，統(tǒng)一的變量名更優(yōu)雅~
????????????此處建議：
? ? ? ? ? ? ? ? ? ? 1）如果項(xiàng)目從頭到尾是一個(gè)人開(kāi)發(fā)的，那么最好從一開(kāi)始就約束該暫存變量名的聲明，即開(kāi)始的時(shí)候聲明為_(kāi)this，那么直到項(xiàng)目結(jié)束都用這個(gè)_this來(lái)暫存this對(duì)象；
? ? ? ? ? ? ? ? ? ? 2）如果是中途接手的別人的運(yùn)維項(xiàng)目，那么在開(kāi)發(fā)過(guò)程中，仔細(xì)留意下已有的代碼里，關(guān)于this對(duì)象暫存的變量聲明，后續(xù)維護(hù)和迭代過(guò)程中，繼續(xù)沿用已經(jīng)約束好的變量聲明；
鳴謝：
