本文最初發布於 Shalitha Suranga 博客,經原作者授權由 InfoQ 中文站翻譯並分享
通常程序員都是為各種類型的軟件項目進行開發工作。當下在基於雲的軟件項目中,更多的程序員是致力於 Web 應用的開發。Web 應用的架構一般是由服務端(API 服務)和客戶端(瀏覽器)兩個相互交互的部分組成。而我們都知道,客戶端主要是用來給用戶呈現內容。
早期的 Web 應用客戶端都是很輕量的,也就是說,在以前的 Web 應用客戶端中處理的業務邏輯比較少。而現在,人們一直致力於構建諸如單頁面應用(SPA)的富客戶端應用,在這樣的富客戶端應用中,客戶端所包含的業務邏輯在數量和複雜度上都絲毫不亞於服務端。
因此,在現代的 Web 應用開發行業中,就需要聘用更多的前端開發人員來完成客戶端的開發工作。現代的前端開發者大部分都是在諸如 React, Angular, Vue, Svelte 等框架上使用 JavaScript 或 TypeScript 進行開發工作。當然也有些程序員會使用架構類似於微前端模式的內部框架進行開發工作。
在我 10 多年的 Web 應用開發工作中,我發現下面這些技巧有助於提高前端開發人員的職業生涯。
當下我們正處於通過使用用戶電腦的計算能力完成 Web 應用業務邏輯執行和交互內容渲染的時代。在早期 Web 應用中,開發人員將所有的業務邏輯都放在服務端執行,客戶端則只負責內容渲染。但是現在更多的 Web 應用通過將 90% 左右的業務邏輯放在客戶端執行來滿足離線應用等需求。
雖然現代的前端框架給開發人員提供了各式各樣的開發模式。但所有主流的框架都對使用 MVVM 模式進行編碼提供了支持。例如:Angular 將 View 和 ViewModel 分離在 2 個獨立文件中(一個 HTML 文件和一個 TS 文件),React 則將 View 和 ViewModel 以組件的形式嵌入在一個 JSX 文件中。
掌握常規 MVVM 模式的知識有助於你快速上手任何前端框架、編寫出簡潔的 UI 控制程序和可測試的代碼。一些開發人員可能會認為 React 既不是 MVVM 也不算 MVC,它只是一個用來操作 View 的庫。然而,它卻讓開發人員以 MVVM 的模式編寫代碼。因此掌握 MVVM 開發模式,有助於開發人員判斷哪些代碼應該寫在 View 中,哪些代碼應該寫在 Controller 中。
一些在意用戶可用性的公司,會聘請 UI/UX 工程師參與到前端開發工作中,甚至有些公司還會成立 UX 團隊,專門用於提高公司產品的可用性。通常,UI/UX 工程師的主要工作是原型設計、可用性測試、CSS 和 HTML 編寫。然而,大多數公司的前端開發人員也會在工作中使用 CSS 和 HTML。
因此,對於前端工程師而言,不管團隊中是否有 UI/UX 工程師,掌握一些一般可行性原則,對其工作都是很有幫助的。例如:你不再需要問 UI/UX 團隊,一個確定按鈕應該放在左邊還是右邊。一般可行性原則可以使我們的 Web 應用更加產品化,更加用戶友好,更加凸顯為用戶考慮。
想象一下,每當你開始一個前端開發任務的時候,就需要考慮設計一致性、組件分類、元素排序、顏色、文本尺寸、文本樣式、動畫、響應設計等因素。然而,大多數應用的原型都沒辦法全部涵蓋。因此,非常有必要花時間學習下一般可用性原則。
使用 JavaScript 機可以寫出同步代碼也可以寫出異步代碼。眾所周知,JS 是單線程的。因此下面這段代碼就會讓瀏覽器卡頓幾秒。
所以我們需要高效利用 JavaScript 的線程機制。出於這個原因,大部分瀏覽器 API 的設計要麼是基於事件機制要麼是基於 promise 的異步機制。例如,當你使用 JS 創建一個 WebSocket 鏈接的時候,JavaScript 不會等待鏈接真正建立完成,就像下面代碼展示的那樣:
因此我們需要訂閱不同瀏覽器在不同時間執行的事件,這導致我們的 JS 代碼變得非常複雜,所以要編寫簡潔的異步代碼還是比較困難的。在處理瀏覽器事件的時候,部分初級工程師傾向於使用 setTimeout 函數的延遲執行來處理,而不使用合理的事件處理函數。這樣就會導致在諸如瀏覽器、弱網、低端設備等不同客戶端上,相同的代碼會出現各種各樣非預期的行為。
所以,儘可能將事件的處理函數放在一個獨立函數體內,避免使用隨機延遲函數處理事件回調,在應用上下文退出的時及時清除事件處理函數,不要使用老的回調模式,使用 async/await 模式(如果非要使用,請使用 promise 轉換下),避免在行內事件處理中添加業務邏輯。
除此之外,經常練習編寫簡潔的代碼是編寫簡潔的同步代碼的秘訣,下面的文章闡述了每個程序員都可以寫出簡潔的代碼。
軟件項目的 5 個簡潔代碼實踐:
https://betterprogramming.pub/5-clean-code-practices-for-every-software-project-479443b31c3c
老版本的瀏覽器提供了基本的 DOM 操作 API。後來,由於 JavaScript 的流行,W3C 引入了許多現代 Web API。因此現在我們可以通過使用客戶端存儲、原生 HTTP 客戶端、語音合成、消息通知等 API 來構建更加用戶友好的 Web 應用。與此同時,現代瀏覽器在 DOM 操作和渲染上的支持上也比以前更加的智能和全面。
例如,以前我們並沒有很好的方法來處理 DOM 元素尺寸變化的事件,而現在我們只需要使用 ResizeObserver API 就能完成。在處理 RESTful 數據請求上,現在我們可以使用更輕量的 Fetch API 完成,而不再需要使用老的基於 XHR 的第三方庫(沒錯,Axios 也是基於 XHR 的)。
因此,在說「這個在用戶瀏覽器中是無法實現的」這句話之前,我們最好先查看下最新的瀏覽器 API。現在我們可以利用 WebAssembly API 在客戶端瀏覽器中運行一些高 CPU 消耗的任務。同時我們還可以利用 web workers 編寫多線程的 JavaScript 操作。現在幾乎沒有人使用 IE11 訪問現代的 web 應用了,所以在使用正式階段(非試驗階段)的 web api 時,不必考慮再三。
不知道你是否關注過慢而臃腫的 Web 應用程序?由於諸如冗餘 UI 元素、靜態資源未做 CDN 加速、沉重的第三方庫或框架等原因,Web 應用通常會變的慢而臃腫。與此同時,如果你將大量的業務邏輯放在客戶端執行,也會導致 Web 應用渲染的比較慢。在不阻塞 JS 線程的情況下,將一些數據的排序和篩選放在客戶端是沒問題的,否則就需要將這些數據處理的操作放在服務端或者數據庫。
雖然 JavaScript 通過非阻塞操作提供了一種類似並行的機制,但一個瀏覽器實例在同一時間點是不能同時完成 2 個 JavaScript 操作的,因此大量的數據操作會必然會讓你的 Web 應用變的很慢。除此之外,過多的事件處理也會影響使 Web 應用變慢。所以需要確保事件處理的高效性,而且在應用上下文退出的時候,也要及時清理事件處理函數。
相對於基於雲計算的後端服務,客戶端的資源是非常有限的。現在,人們依然在使用低端或中端的終端設備訪問互聯網。因此,一旦你在客戶端實現了比較重的功能時,就需要關注 Web 應用程序的內存占用描述文件。例如:下面的內存占用描述文件給出了 YouTube 在視頻播放期間,其內存使用的信息。只需將下面的內存使用統計數據與您正在構建的 Web 應用程序的內存使用情況進行比較即可。
原文鏈接:
https://www.infoq.cn/link?target=https%3A%2F%2Flevelup.gitconnected.com%2F5-skills-that-every-frontend-developer-should-improve-8b613752fa34
點擊底部閱讀原文訪問 InfoQ 官網,獲取更多精彩內容!
西安一碼通半個月崩潰兩次,被工信部點名;快手再傳裁員:最高比例達 30%;阿里調整大淘寶組織架構 | Q 資訊
Apache Flink 不止於計算,數倉架構或興起新一輪變革
解讀開源的 2021:從「開發者亞文化」,變成主流軟件開發模式
阿里正式開源自研 XQUIC:已服務手淘上億用戶,網絡耗時降低超 20%
點個在看少個 bug👇