一些前端問題的總結

本篇內容主要講解“一些前端問題的總結”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“一些前端問題的總結”吧!

代碼邏輯錯誤

「 人很容易發現別人的錯誤，而對自己的錯誤視而不見  」

要想發現代碼邏輯的問題，最簡單的辦法就是看老代碼或者看別人的代碼。代碼邏輯體現的是你對需求的理解，以及你對整個產品邏輯的把控。

比如一個列表的渲染。每一次請求我們都會標記返回的數據列表，記作now_list，然后把列表拼接到現有的列表上面，記作list。當列表底部到頁面底部的距離大于一定數值的時候會自動觸發請求，加載loading。然后判斷當now_list為空的時候，停止自動觸發。這是正常的邏輯。

接下來，騷操作來了，把loading的開啟條件放在了觸發條件里，我們可以記作這個觸發的方法為onEndReached，把關閉loading的方法放在了請求方法里。這樣導致的結果就是當起始數據量小(比如列表長度為1的時候)的情況下，會不斷觸發loading，關閉loading，然后進入死循環。然后又一個騷操作來了，因為每次請求的列表數量為4，所以在onEndReached方法里，添加里一個判斷條件，當now_list的長度小于4的時候，不開啟loading。很簡單的問題繞了一個大圈。而且像這種以數字為條件的的代碼邏輯，一定要引起警惕。因為這預示著你的代碼邏輯不嚴謹。關于代碼邏輯的問題還有多層判斷條件的問題，比如報告的生成與查看，查看報告的按鈕除了不能在狀態1和8展示，其余狀態都可以展示;而下載報告的按鈕只能在狀態5或6展示，分享報告的按鈕只能在6展示。無論查看、下載、分享都操作的是同一個按鈕。像這種邏輯判斷條件多的情況，極易產生錯誤。

產品需求的錯誤

「 需求評審，都是一場辯論會，不是說服別人就是被說服 」不要太相信產品，因為他們也會犯錯誤。總結了一下已知產品需求的錯誤，分兩類：

• 無用的需求

• 不合理的需求

先說一下無用的需求，為什么說是無用的，比如上一版做的功能，下一版全部推翻。也就是說，在上一段時間內，你在做無用功，沒有對產品產生任何價值。一群人白白耗費了一段時間去做了一件毫無意義的事情。再講一下不合理的需求，比如買一贈N，在列表中折疊。不管是贈送的訂單還是正常的訂單，在訂單列表中是平鋪的。為了解決訂單之間的關聯關系，給用戶呈現層級的展示效果，前端需要做的是把平鋪的數據整合成樹狀結構，然后折疊起來，方便用戶查看。列表請求數據條數是一定的，比如4條數據就可以填滿屏幕，我們一般會請求5條，以便上拉加載。那么我們可以假設一下場景，比如買一贈7，當我們首先加載完5條數據，并整合成樹狀結構，折疊起來就變成了一條數據，就會再次觸發請求加載，這次我們又加載了5條，不巧的是下一次的正常訂單也是買一贈7，前3條數據還是上一條的贈送單，那么我們繼續重組數據，現在訂單中有兩條數據，第一條數據折疊了7條，第二條數據折疊了一條，還會繼續觸發請求加載，直到屏幕上放滿了正常的訂單。這個過程會不斷的重組數據，并不斷的加載loading，關閉loading。專業點的術語可以叫"閃屏"。當然可以把折疊的數據默認展開，這也不失為一個好方法。我承認我們做的一些需求不一定合乎規范，并確實解決了一些問題。但是后期的維護實在太困難，而且不可預料。

場景缺失的錯誤

「 改bug，最忌諱的就是改一處，制造兩處 」

場景缺失的問題，也可以簡單的歸為兩類：

• 同樣問題，只改了一處，其他處沒有考慮到

• 關聯問題，只改了有問題的地方，后續產生的問題沒有考慮到

前端時間的地址問題確實困擾了一段時間，側面反應了處理問題不嚴謹，也反應設計之初沒有考慮周全。

省市區的問題，會伴隨著傳值、回顯、提交拼接。問題就出現在了拼接。老數據是直接拼接在一起的，中間沒有任何特殊標記，而現在的需求是第三方拿到這個數據無法解析。舊有的邏輯有自己的一套解析機制，但也存在一定的問題，不嚴謹。所以在已經存在問題的基礎修改，注定還是會存在問題。最好的解決辦法就是推翻重新制定規則。

當我們在解決問題的時候，一定要考慮此處修改的方案是否會對后續邏輯產生影響，尤其是改別人的代碼邏輯，很多問題預料不到，推翻重寫成本太大，所以在以后寫業務代碼的時候一定要解耦，堆在一起的代碼，看的實在頭疼。

異步錯誤

代碼執行的時機一直以來是一個比較嚴重的問題，比如我們常常發現的，數據已經請求到了，為什么頁面沒有顯示。

比如react中的setState，更新DOM樹是一個很耗時的工作，setState會等一個時機做批量的更新，而不是直接更新。

再比如很多同學想在forEach或map中使用async異步函數，但是不要忘了，你接受的結果也是異步的。

概念理解錯誤

還有一些錯誤的因為你對事物本身不了解。

比如前幾天面試，有一個女孩說「 我剛用vue3寫了一個項目 」，那我就問「 那你vue3常用的語法有哪些 」，她的回答「 vue add、vue  ui... 」。我當時腦子就大了。

還有群里哥們問的一個問題：

['1','2','3'].map(parseInt) // [1, null, null] ['1','2','3'].map(Number) // [1, 2, 3] ['1','2DDDD','3'].map(parseFloat) // [1, 2, 3]

問：「 為什么parseInt不可以實現轉化 」

map接受方法參數是固定，只能減少，不能修改，parseInt接受的兩個參數，第二個參數直接被改成了map規定的索引值，再執行parseInt的邏輯，返回的肯定不對了。

換句簡單的理解就是parseInt接受的參數被map強行改為了索引：

parseInt('2',1) // NaN parseInt('3',2) // NaN

到此，相信大家對“一些前端問題的總結”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！