Web 開發人員最常犯的 10 個錯誤：開發人員教程

已發表: 2022-03-11

自從萬維網這個詞在 1990 年被創造出來，Web 應用程序開發已經從提供靜態 HTML 頁面發展為完全動態的、複雜的業務應用程序。

今天，我們擁有數以千計的數字和印刷資源，提供有關開發各種不同 Web 應用程序的分步說明。 開發環境足夠“智能”，可以捕捉和修復早期開發人員經常遇到的許多錯誤。 甚至有許多不同的開發平台可以輕鬆地將簡單的靜態 HTML 頁面轉換為高度交互的應用程序。

所有這些開發模式、實踐和平台都有共同點，並且它們都容易出現由 Web 應用程序的本質引起的類似 Web 開發問題。

這些 Web 開發技巧的目的是闡明在 Web 開發過程的不同階段所犯的一些常見錯誤，並幫助您成為更好的開發人員。 我已經談到了幾乎所有 Web 開發人員都共有的一些一般性主題，例如驗證、安全性、可擴展性和 SEO。 當然，您不應受我在本指南中描述的特定示例的約束，因為它們只是為了讓您了解可能遇到的潛在問題而列出的。

常見錯誤 1：輸入驗證不完整

在客戶端和服務器端驗證用戶輸入是必須要做的！ 我們都知道“不要相信用戶輸入”的明智建議，但是，由於驗證導致的錯誤經常發生。

這個錯誤最常見的後果之一是SQL 注入，它年復一年地進入 OWASP 前 10 名。

請記住，大多數前端開發框架都提供了開箱即用的驗證規則，這些規則非常易於使用。 此外，大多數主要的後端開發平台都使用簡單的註釋來確保提交的數據符合預期的規則。 實施驗證可能很耗時，但它應該成為您標準編碼實踐的一部分，並且永遠不要擱置。

常見錯誤 2：未經適當授權的身份驗證

在我們繼續之前，讓我們確保我們在這兩個術語上保持一致。 正如 10 個最常見的 Web 安全漏洞中所述：

身份驗證：驗證一個人是（或至少看起來是）特定用戶，因為他/她已正確提供了他們的安全憑證（密碼、安全問題的答案、指紋掃描等）。

授權：確認特定用戶有權訪問特定資源或被授予執行特定操作的權限。

換句話說，身份驗證是知道實體是誰，而授權是知道給定實體可以做什麼。

讓我用一個例子來說明這個問題：

考慮您的瀏覽器將當前記錄的用戶信息保存在類似於以下內容的對像中：

 { username:'elvis', role:'singer', token:'123456789' }

更改密碼時，您的應用程序會發出 POST：

 POST /changepassword/:username/:newpassword

在您的/changepassword方法中，您驗證用戶是否已登錄並且令牌尚未過期。 然後根據:username參數找到用戶配置文件，並更改用戶密碼。

因此，您驗證了您的用戶已正確登錄，然後您執行了他的請求，從而更改了他的密碼。 過程似乎沒問題，對吧？ 不幸的是，答案是否定的！

此時驗證執行操作的用戶和更改密碼的用戶是否相同很重要。 存儲在瀏覽器上的任何信息都可能被篡改，任何高級用戶都可以輕鬆地將username:'elvis'更新為username:'Administrator' ，而無需使用內置瀏覽器工具以外的任何其他工具。

所以在這種情況下，我們只負責Authentication以確保用戶提供了安全憑證。 我們甚至可以添加驗證/changepassword方法只能由經過Authenticated的用戶執行。 但是，這仍然不足以保護您的用戶免受惡意嘗試。

您需要確保在/changepassword方法中驗證實際請求者和請求內容，並實施請求的正確Authorization ，確保用戶只能更改她的數據。

Authentication和Authorization是同一枚硬幣的兩個方面。 切勿單獨對待它們。

常見錯誤 3：未準備好擴展

在當今高速發展、創業加速器和偉大創意在全球範圍內即時傳播的世界中，盡快將您的 MVP（最小可行產品）推向市場是許多公司的共同目標。

然而，這種持續的時間壓力導致即使是優秀的 Web 開發團隊也經常忽略某些問題。 擴展通常是團隊認為理所當然的事情之一。 MVP 的概念很棒，但太過分了，你會遇到嚴重的問題。 不幸的是，選擇可擴展的數據庫和 Web 服務器並在獨立的可擴展服務器上分離所有應用程序層是不夠的。 如果您希望避免以後重寫應用程序的重要部分，則需要考慮許多細節——這將成為一個主要的 Web 開發問題。

例如，假設您選擇將用戶上傳的個人資料圖片直接存儲在 Web 服務器上。 這是一個非常有效的解決方案——應用程序可以快速訪問文件，每個開發平台都提供文件處理方法，您甚至可以將這些圖像作為靜態內容提供，這意味著應用程序的負載最小。

但是當您的應用程序增長時會發生什麼，並且您需要在負載均衡器後面使用兩個或更多 Web 服務器？ 即使您很好地擴展了您的數據庫存儲、會話狀態服務器和 Web 服務器，您的應用程序可擴展性也會因為個人資料圖像之類的簡單事情而失敗。 因此，您需要實施某種文件同步服務（這將有延遲並會導致臨時 404 錯誤）或其他解決方法，以確保文件分佈在您的 Web 服務器上。

為了避免這個問題，您首先需要做的是使用共享文件存儲位置、數據庫或任何其他遠程存儲解決方案。 將其全部實施可能會花費幾個額外的工作時間，但這是值得的。

常見錯誤 4：錯誤或缺少 SEO

網站上不正確或缺少 SEO 最佳實踐的根本原因是誤導了“SEO 專家”。 許多 Web 開發人員認為他們對 SEO 有足夠的了解，而且它並不是特別複雜，但事實並非如此。 掌握 SEO 需要花費大量時間研究最佳實踐以及關於 Google、Bing 和 Yahoo 如何索引 Web 的不斷變化的規則。 除非您不斷嘗試並進行準確的跟踪+分析，否則您不是 SEO 專家，也不應該聲稱自己是一名 SEO 專家。

此外，搜索引擎優化經常被推遲，因為一些活動是在最後完成的。 這是以 Web 開發問題為代價的。 SEO不僅僅與設置好的內容、標籤、關鍵字、元數據、圖像alt標籤、站點地圖等有關。它還包括消除重複內容、具有可抓取的站點架構、高效的加載時間、智能反向鏈接等。

與可擴展性一樣，您應該從開始構建 Web 應用程序的那一刻起就考慮 SEO，或者您可能會發現完成您的 SEO 實施項目意味著重寫您的整個系統。

常見錯誤 5：請求處理程序中的時間或處理器消耗操作

此錯誤的最佳示例之一是根據用戶操作發送電子郵件。 開發人員經常認為直接從用戶請求處理程序進行 SMTP 調用和發送消息是解決方案。

假設您創建了一個在線書店，並且您希望從每天幾百個訂單開始。 作為訂單接收過程的一部分，每次用戶發布訂單時，您都會發送確認電子郵件。 一開始這不會有問題，但是當您擴展系統時會發生什麼，突然收到數千個發送確認電子郵件的請求？ 您要么收到 SMTP 連接超時、超出配額，要么您的應用程序響應時間顯著降低，因為它現在處理的是電子郵件而不是用戶。

在您盡快釋放 HTTP 請求時，任何耗時或消耗處理器的操作都應由外部進程處理。 在這種情況下，您應該有一個外部郵件服務來接收訂單並發送通知。

常見錯誤 6：未優化帶寬使用

大多數開發和測試都在本地網絡環境中進行。 因此，當您下載 5 個背景圖像，每個圖像都為 3MB 或更大時，您可能無法識別開發環境中 1Gbit 連接速度的問題。 但是，當您的用戶開始在智能手機上通過 3G 連接加載 15MB 的主頁時，您應該為自己的投訴和問題做好準備。

優化帶寬使用可以極大地提升性能，而要獲得這種提升，您可能只需要幾個技巧。 許多優秀的 Web 開發人員默認做的事情很少，包括：

  1. 縮小所有 JavaScript
  2. 縮小所有 CSS
  3. 服務器端 HTTP 壓縮
  4. 優化圖像尺寸和分辨率

常見錯誤 7：沒有針對不同的屏幕尺寸進行開發

在過去的幾年裡，響應式設計一直是一個大話題。 具有不同屏幕分辨率的智能手機的擴展帶來了許多訪問在線內容的新方式，這也帶來了許多 Web 開發問題。 來自智能手機和平板電腦的網站訪問量每天都在增長，而且這一趨勢正在加速。

為了確保無縫導航和訪問網站內容，您必須使用戶能夠從所有類型的設備訪問它。

構建響應式 Web 應用程序有許多模式和實踐。 每個開發平台都有自己的技巧和竅門，但有些框架是平台獨立的。 最受歡迎的可能是 Twitter Bootstrap。 它是一個開源且免費的 HTML、CSS 和 JavaScript 框架，已被各大開發平台採用。 只需在構建應用程序時遵循 Bootstrap 模式和實踐，您就可以毫無問題地獲得響應式 Web 應用程序。

常見錯誤八：跨瀏覽器不兼容

在大多數情況下，開發過程都承受著巨大的時間壓力。 每個應用程序都需要盡快發布，即使是優秀的 Web 開發人員也經常專注於提供功能而不是設計。 儘管大多數開發人員都安裝了 Chrome、Firefox、IE，但他們在 90% 的時間裡只使用其中一種。 在開發過程中使用一個瀏覽器是常見的做法，當應用程序接近完成時，您將開始在其他瀏覽器中測試它。 這是完全合理的——假設您有大量時間來測試和修復現階段出現的問題。

但是，當您的應用程序進入跨瀏覽器測試階段時，有一些 Web 開發技巧可以為您節省大量時間：

  1. 開發過程中不需要在所有瀏覽器中進行測試； 這是耗時且無效的。 但是，這並不意味著您不能經常切換瀏覽器。 每隔幾天使用不同的瀏覽器，您至少會在開發階段的早期發現主要問題。
  2. 小心使用統計數據來證明不支持瀏覽器。 有許多組織在採用新軟件或升級方面進展緩慢。 在那里工作的成千上萬的用戶可能仍需要訪問您的應用程序，並且由於內部安全和業務政策，他們無法安裝最新的免費瀏覽器。
  3. 避免瀏覽器特定的代碼。 在大多數情況下，有一個優雅的解決方案是跨瀏覽器兼容的。

常見錯誤 9：沒有為可移植性做規劃

假設是所有問題的根源！ 談到便攜性，這句話比以往任何時候都更加真實。 您在 Web 開發中遇到過多少次問題，例如硬編碼文件路徑、數據庫連接字符串或某個庫將在服務器上可用的假設？ 假設生產環境將匹配您的本地開發計算機是完全錯誤的。

理想的應用程序設置應該是免維護的：

  1. 確保您的應用程序可以在負載平衡的多服務器環境中擴展和運行。
  2. 允許簡單而清晰的配置——可能在單個配置文件中。
  3. 當 Web 服務器配置不符合預期時處理異常。

常見錯誤 10：RESTful 反模式

RESTful API 已在 Web 開發中佔據一席之地，並將繼續存在。 幾乎每個 Web 應用程序都實現了某種 REST 服務，無論是供內部使用還是與外部系統集成。 但是我們仍然看到不符合預期實踐的損壞的 RESTful 模式和服務。

編寫 RESTful API 時最常犯的兩個錯誤是：

  1. 使用錯誤的 HTTP 動詞。 例如使用 GET 寫入數據。 HTTP GET 被設計為冪等且安全的，這意味著無論您在同一資源上調用 GET 多少次，響應都應該始終相同，並且應用程序狀態不應發生變化。

  2. 未發送正確的 HTTP 狀態代碼。 此錯誤的最佳示例是發送響應代碼為 200 的錯誤消息。

     HTTP 200 OK { message:'there was an error' }

當請求沒有產生錯誤時，您應該只發送 HTTP 200 OK。 如果出現錯誤，您應該發送 400、401、500 或任何其他適合已發生錯誤的狀態代碼。

可以在此處找到標準 HTTP 狀態代碼的詳細概述。

包起來

Web 開發是一個非常廣泛的術語，可以合法地包含網站、Web 服務或複雜 Web 應用程序的開發。

本 Web 開髮指南的主要內容是提醒您，您應該始終小心身份驗證和授權，計劃可擴展性，並且永遠不要倉促假設任何事情 - 或準備好處理一長串 Web 開發問題！