曾經在大學的時候負責過學校網站的運維（從內存條、PCI到HTTP服務器那種），后來工作了在百度開始做運維自動化的開發，再后來又帶著20多個人的團隊在360從零開始做了兩個Android的項目，我想我還是有資格說說運維和開發的關系的：我認識很多運維，工作了2~3年后普遍覺得自己就是個操作員，天天半夜起來“抗洪救災”不說，還偶爾背黑鍋。到了年終大頭都讓研發、產品、測試分了……但請不要抱怨，想一想，如果自己是老板會不會這么做呢？研發、產品就像Dota里的DPS和Gank，是左右戰局發展的；測試、運維一個是奶媽，一個是肉不被重視是很自然的。運維和開發是互聯網大生產時代分工的必然結果，但如果你畫地為牢，就不要抱怨別人為什么過得更好
我想說的是：
不要把運維當作一種職業去發展，一般運維做2~3年就會遭遇瓶頸期工程開發人員想要有深入的發展，必須懂一定的系統運維如果你是運維，請明白一個程序能穩定運行在線上，不是什么魔法，是研發的付出由于PaaS的迅猛發展，傳統運維的工作（配網絡設備，服務器物理操作）將會越來越少，建議運維人員向運維開發或者系統開發轉型如果你是開發，請尊重團隊的成員，不要給別人憑添麻煩，如下在BAT的經歷讓我總結了一個道理：“寫出需要別人擦屁股的程序，是一個開發人員的恥辱”。大學的時候有幸接觸了Linux網站運維的工作，勤工儉學負責了學校網站的運維工作，現在回頭看來這份工作的技術含量不是很高。當時覺得最牛的事情就是做做內核裁剪，后來由于好奇心的驅使，初生牛犢不怕虎，斗膽修改了proftpd的代碼。從此走上了系統開發的不歸路，由于深知系統運維的工作的枯燥，我給自己開發的程序定下了幾個原則：
不能崩潰，要有自己的崩潰恢復機制，tj/mon · GitHub內存泄漏，句柄泄露這種事情決不允許發生，Valgrind盡量靜態依賴所有的庫，除了常見的libc、libm等什么都不要依賴，做到丟到服務器上就能運行，像這樣miniPy for CentOS 5/6和 異步多線程C/S框架gko_pool做好start、stop、restart腳本能通過參數傳遞實現的功能，絕不要求寫配置文件，auxten/gingko · GitHub默認參數就是最佳配置，同樣參見上面的項目能自己處理日志，自帶rotate功能，同樣參見上面的項目Web 前端開發大致上是，創建出 Web 網頁以供用戶瀏覽使用等。主要通過 HTML、CSS、JavaScript 等技術來實現交互。
所面臨的挑戰主要有幾點：
一、
Web 的載體的多樣性。
以瀏覽器為例，分別有 IE，Chrome，火狐等。雖然有 ECMA 委員會進行標準化，但不同瀏覽器對 HTML、CSS、JS 等支持程度還是存在差異。所以需要進行兼容處理。
而且，這還會另測試的復雜度上升。
二、
Web 前端開發的工程化問題。
在以前，Web 前端開發是極度依賴于后端的，例如 JSP、PHP 等前后端代碼混雜，這段時期，前端的工程化問題還不算凸顯。
而隨著 MVVM 的普及，前后端的分離，本身的前端項目需要有一定的組織，協作，需要有前端的一套工程化解決方案。
包括組件化開發，單元測試，增量更新，代碼壓縮混淆，項目的打包構建發布等。
三、
Web 框架之間的不兼容。
Web 開發中，躲不開的是三大框架 React、Angular、Vue。而框架與框架之間存在明顯的溝壑。
對于一個 Web 前端項目來說，其實使用哪種技術并不重要，重要的是能實現需求。但是在實際上，如果項目選定了某個框架，其他框架之間的某些組件或者解決方案并不能互通。
當然，現在的 Web Component 有希望解決這個問題，但是， Web Componet 的兼容性也存在明顯問題。
結語：
Web 前端開發所面臨的問題遠不止這些。當然，有問題就有解決方案，Web 前端技術就是在攻克這些問題上不斷演進。
web前端即為網站的前端開發,前端開發是創建Web頁面或app等前端界面呈現給用戶的過程。 web前端開發通過HTML,CSS及JavaScript以及衍生出來的各種技術、框架、解決方案,來實現互聯網產品的用戶界面交互。
1.根據項目或者產品需求負責實現PC端及移動頁面的設計和開發、調試等工作，高效、高質地完成代碼編寫，確保符合前端代碼規范;
2、與后端開發團隊緊密配合，完成接口對接，確保前后端有效交互共同完成項目或者產品;
3、綜合運用客戶端和服務器端構建與優化方案、模塊化開發等手段，提升開發效率和系統性能;
4、持續優化前端應用，改善用戶交互以及視覺，保證前端網頁的兼容性以及頁面響應速度并負責前端代碼的維護，
5、了解并結合業務需求，設計滿足用戶需要、符合用戶習慣、運用大數據分析能力、體現大數據特色的系統。
6.與設計師、產品工程師緊密工作在一起,實現產品前端ui和交互方面的開發需求，確保不同平臺、設備上具有優秀的用戶體驗；