在製做網站以前,前端程序員應該考慮哪些技術細節?

原文地址:What should every programmer know about web development?php

界面和用戶體驗

  • 注意瀏覽器的實現標準上的不一致,確保你的網站在全部主流瀏覽器。至少須要測試最近的Gecko 引擎(Firefox)、Webkit引擎(Safari和一些手機瀏覽器)、Chrome、你支持的IE瀏覽器(利用IE應用程序兼容性VPC鏡像)和Opera。也要考慮在不一樣操做系統上瀏覽器如何渲染你的網站
  • 考慮人們可能使用主流瀏覽器之外的方式來訪問網站:例如手機、屏幕閱讀器和搜索引擎。一些輔助信息: WAI 和 Section508,移動開發: MobiForge
  • 模擬環境:如何不影響用戶地部署更新。有一個或多個測試或部署環境來實現框架、代碼或清除內容的改變並確保它們可以以一種可控制的方式部署,而不破壞任何東西。有自動方法部署許可的更改到線上環境。這是最有效地實現結合使用版本控制系統(CVS, Subversion等)和自動化構建機制(Ant, NAnt等)。
  • 不要直接給用戶顯示不友好的錯誤信息。
  • 不要把用戶的郵件地址以明文顯示出來,這樣用戶的郵箱會被垃圾郵件搞死。
  • 添加rel=「nofollow」屬性的用戶生成的連接,避免垃圾郵件
  • 爲你的網站設置一些合理的使用限制(這也與網站安全相關。)。
  • 知道如何實現漸進加強
  • 用戶發出POST請求後,老是將其重導向(redirect)至另一個網頁。
  • 不要忘記網站的可訪問性(accessibility,即殘疾人如何使用網站)。對於美國網站來講,有時這是法定要求WAI-ARIA有一些這方面很好的參考資料。
  • Don't make me think

安全

性能

  • 有必要的話,就使用緩存。理解和合理使用HTTP cachingHTML5離線儲存
  • 優化圖片。不要使用20KB的圖片文件平鋪背景。
  • 學習如何用 gzip/deflate 壓縮內容。
  • 合併/鏈接多個樣式表或腳本文件來減小瀏覽器的 http 網絡鏈接數以及減少 gzip 壓縮後的文件整體積。
  • 學習一下 Yahoo Exceptional Performance 這個網站上的東西,上面有不少很是不錯的改善前端性能的指導,以及 YSlow 這個工具。 Google page speed 是另外一個用來作性能採樣的工具。這兩個工具都須要安裝 Firebug
  • 用到大量的小體積圖片(好比工具欄)的地方使用 CSS Image Sprite,目的是減小 http 請求數。
  • 用到大量的小體積圖片(好比工具欄)的地方使用 SVG Image Sprite。SVG的着色是有點棘手。你能夠在這裏閱讀
  • 大流量的網站應該考慮將網頁對象分散在多個域名。(好比有專門的圖片服務器——圖片至關耗帶寬,或是專門的 Ajax 服務器)。
  • 靜態內容(好比圖片、CSS、JavaScript、以及其餘cookie無關的網頁內容)都應該放在一個不須要使用cookie的獨立域名之上。由於域名之下若是有cookie,那麼客戶端向該域名發出的每次http請求,都會附上cookie內容。這裏使用內容分發網絡(CDN)的一個很好的選擇,但考慮這樣的情形,CDN may fail by including alternative CDNs, or local copies that can be served instead.
  • 將瀏覽器完成網頁渲染所須要的http請求數最小化。
  • 選擇一個模板引擎並使用自動化構建工具如gulp或grunt渲染/預編譯它。
  • 確保網站根目錄下有 favicon.ico 文件,由於即便網頁中根本不包括這個文件,瀏覽器也會自動發出對它的請求。因此若是這個文件不存在,就會產生大量的 404 錯誤,消耗光你的服務器的帶寬。(服務器返回 404 頁面會比這個 ico 文件可能還大)。

SEO

  • 使用"搜索引擎友好"的URL形式,好比example.com/pages/45-article-title,而不是example.com/index.php?page=45。
  • 若是你的動態頁面要使用 # ,那麼請把其改爲 #! ,而在服務端,你須要處理$_REQUEST["_escaped_fragment_"] 這是 Google 搜索引擎須要的。換句話說,./#!page=1 會被 Google 搜索引擎轉成 ./?_escaped_fragments_=page=1。另外,用戶也許會使用 Firefox 或 Chromium, history.pushState ({"foo":"bar"}, "About", "./?page=1"); 是一個很不錯的命令。因此,就算是咱們的地址欄上的地址改變了,頁面也不會從新裝載。這可讓你使用 ? 而不是 #! 也能無刷地保住當前的動態的頁面,這可讓 AJAX 的請求被瀏覽器記住。
  • 要使用"點擊這裏"之類的超級連接,由於這樣等於浪費了一個SEO機會,並且對使用屏幕閱讀器的人更難操做。
  •  建立一個 XML sitemap 文件,它的缺省位置通常是/sitemap.xml(即放在網站根目錄下)。(這個文件可讓搜索引擎瞭解你的網站地圖)
  • 當你有多個 URL 指向同一個內容時,在網頁代碼中使用<link rel=」canonical」 … />。可使用 Google Webmaster Tools 來查看相關的問題。
  • 使用 Google Webmaster Tools  和  Bing Webmaster Tools
  • 從一開始就使用 Google Analytics(或者開源的訪問量分析工具 Piwik
  • 瞭解 robots.txt 和搜索引擎爬蟲是如何工做的。
  • 將www.example.com的訪問請求導向example.com(使用301 Moved Permanently重定向),或者採用相反的作法,目的是防止Google把它們當作兩個網站,分開計算排名。
  • 知道並非全部的爬蟲都是好的,有些爬蟲的行爲並很差。(好比向你的網站發大量的請求致使服務器性能低下)
  • 若是你的網站有非文本的內容(好比視頻、音頻等等),你應該參考 Google 的 sitemap 擴展協議Tim Farley 的答案,可讓你看到不少有價值的東西。

技術

  • 理解 HTTP 協議,以及諸如 GET、POST、sessions、cookies 之類的概念,包括」無狀態」(stateless)是什麼意思。
  • 讓你的 XHTML/HTML 和 CSS 符合 W3C 規範,使得它們可以經過檢驗。這可使你的網頁避免觸發瀏覽器的怪異模式(quirks mode),而且可讓其更容易地能和非標準的瀏覽器工做,好比讀屏器或移動設備。
  • 理解瀏覽器是怎麼處理 JavaScript 。
  • 理解網頁上的 JavaScript 文件、樣式表文件和其餘資源是如何裝載及運行的,考慮它們對頁面性能有何影響。現在普遍地認爲適當地將腳步放到頁面的底部但典型的例外是分析app或HTML5 shime。
  • 理解 JavaScript 沙箱(Javascript sandbox)的工做原理,尤爲是若是你打算使用 iframe。
  • 知道JavaScript可能沒法使用或被禁用,所以Ajax是一種延伸,不是一個基準。就算是大多數用戶都開啓了 Javascript 功能,記住NoScript正變得愈來愈流行,移動設備可能沒法按預期的工做,而Google索引網頁時不運行大部分的腳本文件。
  • 瞭解 301 重定向和 302 重定向之間的區別(這也是一個 SEO 相關問題)。
  • 儘量多地瞭解你的部署平臺。
  • 考慮使用 Reset Style Sheet 或 normalize.css
  • 考慮JavaScript框架(如 jQueryMooToolsPrototypeDojo or YUI 3),使用JavaScript操做DOM時可使你不用考慮瀏覽器之間的差別。
  • 把perceived performance和JS框架結合,考慮使用服務如Google Libraries API 來加載框架所以瀏覽器可使用它緩存好的框架的副本而不是從你的網站下載一個重複的副本。
  • 不要從新發明輪子。在作任何事以前尋找一個現有組件或例子。你有 99% 的可能找到別人已經發布的開源版本。
  • 不要一開始就作很是多的功能和組件,特別是在客戶端的 Web 上,你須要保持系統是輕量級,快速,靈活的。

修復bug

  • 要知道你將花20%的時間寫代碼剩下80%來維護,因此你要當心編碼。
  • 創建一個有效的錯誤報告機制。
  • 創建某些途徑或系統,讓用戶能夠與你接觸,向你提出建議和批評。
  • 爲你開發的東西造成文檔,解釋清楚系統是怎麼運行的,這樣可讓後來的人容易維護你的軟件和系統。
  • 頻繁備份(也可確保你的這些備份功能正常)你還須要有一個恢復策略,而不僅是一個備份策略。
  • 使用一個版本控制系統來保存你的代碼,如: Subversion、 Mercurial 或 Git。不要忘了作驗收測試,想Selenium這樣的框架能幫助你。
  • 特別 地若是你想讓測試徹底自動化,或許使用像Jenkins的持續集成工具。
  • 當你寫日誌的時候,確保你記錄了你捕獲了處理和未處理異常。報告和分析日誌可讓你知道你網站的問題。

其餘

  • 實現服務器端和客戶端的監控和分析( 應該是積極的,而不是被動的)。 
  • 使用UserVoice 和 Intercom(或任何其餘相似的工具)不斷保持與用戶聯繫。
  • 遵循 Vincent Driessen  的 Git分支模型
相關文章
相關標籤/搜索