網站開發服務端與前端協同參數以及外企的網站運維和上市公司的前端開發該選哪個相關疑問，小編匯總各路說法：

1、網站開發服務端與前端協同參數，外企的網站運維和上市公司的前端開發該選哪個？

曾經在大學的時候負責過學校網站的運維（從內存條、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功能，同樣參見上面的項目

2、前端開發要到什么水平才是中級開發？

處理問題的思路以及解決問題的能力，多種方案。

對于當前框架的使用熟練度，特別熟悉。

是否嘗試自己造輪子。

對于框架內部需求業務模塊的優化。

rest接口數據結構的約定，與優化內部組建之間的通用參數。

多框架對比或者單一框架兼容方案。

js原生基礎，對于普遍使用js原生的熟悉與理解。

到這一步可以嘗試往高級走了。

3、前端和后端交互是怎樣的步驟？

一般來說，前端用的是JS，與后端交互是Ajax。

過程如下：

一、前端組織參數列表，采用get或post方式提交到指定的URL。

二、URL就是后端程序，先接收參數，根據參數值確定執行的程序功能，執行后將執行結果輸出到前臺。

三、Ajax將“二”中的返回值進行解析，根據相關條件更新前端界面就可以了。