學web前端開發寫給新手的建議，超實用！

01 
前面的話

現在咱們使用的互聯網，客戶端與服務器端的交互無時無刻不在發生。好比咱們在瀏覽器打開網頁，瀏覽器就是客戶端，將網頁數據發過來的也就是服務器。其實服務器，並無什麼特別的，也就是一臺晝夜不停運轉的電腦罷了。每一臺入網的機器，都會被分配一個ip，咱們能夠經過ipconfig / ifconfig這樣的命令，知道咱們電腦的ip地址。服務器自己，運行着服務器程序，他們監聽着來源於網絡的請求，並對請求進行響應。

比較常見的服務器程序，好比apache / Nginx / IIS等等，咱們能夠經過如下這樣的一個小的實驗，來了解網絡中的客戶端與服務器，是如何進行交互的。

實驗：一個小的局域網

第一步：運行你電腦上的服務器程序（以apache爲例，建議使用xampp / wamp這樣的軟件包，win下一鍵安裝，能省很多事。固然，喜歡折騰的同窗和SA們確定要一個一個裝啦），在apache的www目錄下放入一些網頁文件，而後在瀏覽器的localhost下瀏覽網頁。

第二步：在電腦上打開wifi共享軟件，經過ipconfig / ifconfig命令查看本機在內網的ip，讓手機鏈接電腦共享的wifi（或者是二者同連一個路由器的wifi），在手機瀏覽器的地址欄輸入電腦的ip，進入電腦的服務器並瀏覽網頁。

上面的小實驗的第二步，就模擬了一個簡單的瀏覽器+服務器系統（BS系統），也在必定程度上反映了網站基本的訪問原理。同時，這也是Web前端開發中真機測試移動端頁面的一個行之有效的方法；固然，你也能夠經過這種方式，實現局域網絡的文件共享。

繼續深刻一步，咱們在瀏覽網站的時候不多使用ip直接訪問的，而是用www.baidu.com這樣的域名，域名與提供對應服務的服務器的ip地址經過DNS服務器相互對應。咱們能夠經過ping命令，也能夠經過一些在線的工具，如http://ping.chinaz.com來獲取一個網站的ip地址，有時候ping出來的ip是不同的，通常和你使用網絡的地點有關，這主要是爲了將對服務器的請求分流，減輕服務器的壓力，保證網站的訪問速度（好比能夠了解一下CDN）。（web前端學習交流羣：328058344 禁止閒聊，非喜勿進！）

02 
開發的過程與設計的藝術

如何從0創建一個網站，這就涉及到軟件產品的開發了。通常，會有如下幾個職位。

產品（PM）：負責對軟件產品的功能，目標用戶等許多部分，進行一個詳細的概括整理，包括前期的功能地位和後期的功能修繕；

設計（UE）：對用戶使用的產品界面、交互方式進行統籌和設計；

前端（FE）：活躍於前端的程序員，負責使用代碼實現設計師的設計，並與後端協調數據在客戶端的渲染工做；

後端（BE）：活躍於服務器端的程序員，爲前端的渲染提供所需的數據；

系統（SA）：保證開發過程當中，對於服務器權限的管理與協調，以及服務器運行環境的提供，同時保證網站在生產環境中的平穩運行。

限於我的能力，我在此僅從前端和後端這兩個角度，探討網站實現的技術細節，其中會涉及許多具體的解決方案，供你們參考。

如今咱們從這樣的角度去看一個網站，我將他分爲三層，視圖層，數據層，以及控制數據在視圖上的顯示方式的控制器。

舉個例子，一個留言板，他的數據層會包括留言者的留言內容、留言時間、留言者的信息等內容。這些數據，就像一張excel表格同樣，存儲在咱們的服務器。而咱們的用戶確定不但願看到一個簡陋的表格，他們但願看到的至少是一個界面，數據內容被清新美觀的顯示在咱們的瀏覽器上，而這個界面，也會隨着數據內容的增刪修改而作出相應的調整。存儲表格數據的，就是數據層；用戶看到的，就是視圖層；讓界面隨數據產生改變，則是控制器的使命。

如今，從技術的角度咱們去實現他。首先，前端工程師根據設計師的設計，作出視圖層的模板，後端工程師也作好相應的數據存儲工做，包括設計建立數據庫、數據表等等。如今，基本的工做完成。繼續下去，咱們則有不少的選擇。

選擇一：後端渲染數據到視圖

這種方法，就是前端將模板交給後端，告訴後端具體在哪一個位置放什麼樣的數據，放的時候有什麼具體的要求，剩下的渲染工做徹底交給後端處理。這樣的方法實現起來門檻低，並且因爲服務器計算性能通常狀況下強於客戶機，後端來刷模板簡單粗暴速度快，沒有任何爭議。缺點是後端工程師因爲處理了數據填寫的工做，至關於涉及了視圖層（即前端）的工做內容，致使分工不夠明確；同時，因爲是後端更新數據，然後端代碼是運行在服務器上的，每次要更新都要刷新頁面從新請求一個完整的頁面，某種意義上來講，用戶體驗相對較差。

選擇二：後端將數據生成爲小的數據文件，前端獲取數據並由前端更新視圖。

這種方法，涉及到前端的Ajax。說白了就是在後臺異步加載另一個頁面，在加載過程當中用戶不會看到任何變化，而加載完成後，至關於在前端程序裏獲取了一個字符串，剩下的任務就是將這個字符串解析取出裏面的數據並將對應內容渲染到相應的位置上。經過這種方式，首先能夠保證視圖層顯示的內容都徹底由前端工程師負責，分工明確，實現了必定程度上的先後端分離；同時，與服務器交互的文件大小，從一整個頁面縮小到了一個僅僅包含要更新的數據的小文件，交互的量減少，帶來性能上的提高；另外，因爲交互文件通常使用json這種多數編程語言均可以解析的數據格式，不只能夠給網頁前端使用，也能夠給移動端app的前端開發使用，統一了接口，擴展時減少了工做量。

選擇三：單頁應用（SPA）

我先解釋一下單頁應用，和傳統網站相比，他更接近於移動端應用程序，其核心就是將路由控制在前端工程師的手裏。核心技術除了上面的Ajax，還有pushState，又有人將二者合稱爲PJAX。

先說什麼是路由，路由能夠理解爲你網站域名後面的內容，好比www.abc.com/p/123這樣的網址，後面的/p/123就標明瞭一個路徑。能夠類比於咱們電腦的磁盤，當我在路徑的位置輸入C:/p/123的時候，我但願看到C盤下p文件夾下123文件夾的內容，當123變成了456，顯示的內容應該有些變化。若是456文件夾存在，顯示該文件夾的內容；若是不存在，則會彈出錯誤信息提示不存在。對應咱們的網站，若是當/p/123變成/p/456的時候，也應該給出對應的顯示。路由由前端控制的含義，就是說，網站url的變化與對應的顯示由前端處理。你的整個網站實際上只有一個頁面，前端根據url的變化，經過Ajax異步加載須要的數據，而後經過pushState操做瀏覽器的歷史記錄，達到與瀏覽普通網站一樣的效果。

SPA最大的優勢，大概就是響應速度了。固然，使用SPA對前端的技術提出了相對比較高的要求。使用SPA的通常狀況，是你要作一個相似於安卓app的網站，如淘寶的手機站和Gmail，都是至關典型的SPA。不過，雖然如今SPA不少，並非全部的場景都適合使用SPA的。

淘寶收藏夾的架構：

做爲訪問量如此高的網站，淘寶是怎麼作的。（首先，php的後臺確定是擔負不起這樣的訪問量的。）在淘寶UED，他們介紹了「中途島」項目，基本架構是：前端工程師使用Node.js進行模板渲染，保證模板的渲染由服務器完成提升效率；Node.js訪問由java後臺封裝的高級數據接口，而java在訪問數據庫的時候，則是使用C語言來實現最有效率的訪問。技術細節能夠參考淘寶UED的博客。

03 
項目開發中值得一提的點

關於查閱資料和提問：

遇到問題先問搜索引擎，這我想應該都沒有什麼意見。用不了谷歌，能夠從laod.cn下個hosts，翻出去的話，方法太多，不廢話了。

固然了，找不到具體問題問人是不可避免的。可是當問題比較複雜的時候，好比前端這邊處理瀏覽器兼容問題的時候，必定要有在線demo，必定要把問題描述的很清楚而且真的是本身解決不了了再問。關於提問的藝術，能夠看看張鑫旭大神的博客（我的很是喜歡，強烈推薦前端同窗關注），如何提問才能進階成爲前端大神？，這篇文章對提問須要注意的點說的很是明確，請你們，不管是否是作前端，最好都看看。

任務進度管理：

雖然在學校裏作東西，不多會有嚴格的工期安排、進度計劃這些，可是在公司裏，這些問題確定是會遇到的。推薦幾個工具，你們能夠了解一下：tower和微軟的project。

版本控制：

幾乎沒有任何成功的軟件項目，是一個敲代碼敲出來的，何況，就算是一我的敲代碼，也應該對本身所作的改動有所記錄和備份。在這裏，我將介紹兩種使用git進行版本控制的方式，供你們參考。

分支管理：

整個項目是一個大的倉庫，這個大的倉庫因爲不一樣的修改而有不一樣的分支。通常來講，有master（穩定發佈版本） / dev（開發中的相對穩定版本） / 開發人員我的分支（集中我的的修改）這些。通常的工做過程爲，我的會在我的的分支上修改，而後push到dev分支，穩定下來的dev分支做爲新的版本再合併到master分支。那一部分出了問題，就在哪一部分進行修改。git在你每次更新分支的內容時都要求你輸入一段描述修改的文字，這在未來的版本控制和回退上都會頗有幫助。

倉庫管理：

我的理解實際上是擴大化的分支管理，項目負責人創建項目倉庫，項目開發人員fork母倉庫，作了本身的修改後，對母倉庫發出pull request，申請合併到母倉庫。這一方法最大的優勢，就是方便負責人進行code review，保證代碼質量；同時也能夠方便對開發人員的貢獻度進行考覈。一般公司裏會選取這種方式。

項目的持續集成：

持續集成你們在學校也不多會接觸到，可是當你在公司裏，遇到大項目的時候，就確定會接觸到持續集成這方面的需求和工具。我的認爲持續集成更像是一種思想，在項目的開發過程當中，前端和後端在開發過程當中不斷的對接，測試樣例提早都作好，而後自動化構建項目，自動化測試等等。每當代碼庫更新（固然，本地構建失敗的代碼是不容許提交到倉庫的）的時候，自動構建腳本、自動測試腳本都會跑出一個更新後的產品給你們看，方便團隊中的每個人掌握項目的狀況和目前的進度。

實現這種思想，就須要與之配合的工具，關於持續集成這方面如今在企業中目前尚未「最佳實踐」，不過確實有不少前人的經驗供我們借鑑，如《持續集成最佳實踐》裏面對於持續集成實踐進行了思考

04 
幾點建議

在學習開發技術的過程當中，我的給你們一點建議：

• 前期初學的時候，千萬不要求多

道理你們都明白，什麼都想學確定什麼都學很差。若是一我的都能學過來，那麼咱們還搞這麼多方向作什麼。有些東西，當你須要的時候，天然就會接觸到；而那個時候你再學，你確定是在實際項目中遇到了什麼問題。有問題導向的學習是很是有效率的，因此千萬不要求多，穩住。

• 千萬不要剛剛入門就以爲本身什麼都會了

這是我經歷過的階段，當時被一位學長拉了回來，也是很是幸運。這個階段你以爲本身清楚不少東西了，感受只要查查資料本身什麼都能解決。其實想想，這麼多人研究這個領域，你怎麼可能立刻就看透了他呢。每一個領域，都有不少坑，每個坑也都會有至少一個與之對應的解決方案，而處理項目和解決方案，是一條漫長的道路。知識是越學越細的，原本你覺得前端只能寫寫頁面，深刻學習之後，你纔會發現，js能夠寫機器人；能夠調系統API作桌面應用；哪怕只是在寫頁面這部分也有着頁面渲染時間、內存泄漏等各類各樣的問題和與之對應的層出不窮的解決方案。因此，低調，前面的路還很長。

• 學到必定程度，能夠多去看看

咱們知道書本上的知識確定不是最新的，技術在不斷的發展。可能你如今用的書上的代碼都已通過時到運行不了了。這個，其實很正常，畢竟作網絡這方面，怎麼可能光靠書來追蹤技術呢。因此多去看吧，github，各類社區、論壇，線下的技術交流，這些能夠給你帶來最新鮮的營養。因此，世界這麼大，出去多看看。

05 
結語

寫代碼，按照本身的意願去構建一個產品，一個項目，哪怕再小，依然是自由的。哪怕是在實現別人的需求，能夠作好，作精，作出一套最佳的解決方案（沒有最佳，只有最適合項目），給別人留下輪子去作好二次開發，依然是自由的，是有意義的。