前言
猿題庫剛剛結束了北京地區的大規模校園招聘，國慶之後打算轉戰外地進行校招。我本人深度參與了此次的校招工作，包括筆試題命題、面試題命題以及具體的面試工作。
我在面試中發現了一個非常有意思的現象，就是大多數應屆生都想做服務器端開發，但是他們卻又不清楚服務器端開發具體要做些什麼。
我和同事聊天的時候說起此事，我們認為可能應屆生覺得：做服務器端開發可以讓自己寫的程序運行在很多臺機器上，並且處理海量的數據，這很「牛逼」。而做客戶端或前端開發太簡單，成長會比較小。
於是我就寫了本文，想給這些單純的應屆生潑潑冷水。先說說我的背景吧，我同時做過服務器端和客戶端的開發。我在網易有道做過 1 年半的服務器端開發，產品涉及網易郵箱和微博產品，之後做了 3 年的 iOS 開發，產品涉及有道雲筆記，猿題庫和小猿搜題，所以我能夠給大家分享服務器端和客戶端開發的差別。
對服務器開發的誤解
很多應屆生認為做服務器端開發可以處理海量數據，管理上百臺服務器。
但是 ——
處理海量數據就牛逼了？NO！
服務器端開發經過多年的發展，對於海量數據的處理早有了很多固定的解決方案。不管是用雲服務，還是用 Hbase ，你都可以很輕鬆地依賴開源庫，解決海量數據的存儲問題。
還有一些同學想做大數據分析，如果你寫過 MapReduce 程序就不會這麼想了。現在的 MapReduce 程序寫起來太 easy 了，很多時候簡單到你就只需要寫一條類似 SQL 的查詢就行了。
運行在上百臺服務器上就牛逼了？NO！
現在虛擬化技術發展迅猛，像小猿搜題所有服務都通過 Docker 來部署。很多時候，部署上線就是在 Web 管理界面上點擊一個「Deploy」按鈕即可。即使在過去，實際操作這些上百臺服務器的也是運維同學，輪不到你來操作。
所以，除了 YY 一下這些程序跑在多個機器上，這並沒有什麼可以帶來成就感的地方。
還有一些應屆生覺得自己在學校做過網站，覺得在服務器開發方面有基礎，做這方面更順手。NO！企業裡面的服務器開發完全不是你想的那樣，基本上大家在學校做網站的經驗等於零。
服務器開發的苦
我給大家分享一下做服務器開發有什麼苦的地方吧。
永遠只能半夜上線
做為互聯網公司，我們希望給用戶提供 7 x 24 的不間斷服務，那麼服務萬一需要中斷怎麼辦？半夜上線唄。
根據我多年的觀察，晚上 12 點一般都是上網高峰，所以上線一般都是凌晨 3 點-4 點的時候進行。但是，你以為上線就是凌晨 3 點點一下「Deploy」按鈕就完了嗎？NO! 一般上線都會涉及功能升級，難免會有考慮不周到的情況，於是就會發生，上線出問題的情況。
上線出問題怎麼辦？在網易，我們一般是兩種做法：
在線調試和修改 Bug，通常順利的話，到早上 7，8 點的時候一般就能搞定了。
在線調試和修改 Bug，如果不順利的話，到早上 7，8 點的時候回滾數據。然後，我們需要回家休息半天之後，繼續在下一個凌晨 3 點上線。
當然，不會每次上線都是這種大升級，但是基本上，1、2 個月搞一次這種大上線還是挺常見的。
相對來說，客戶端同學在這方面要輕鬆得多。iOS 和 Android 都是提交應用市場審核，所以客戶端的同學可以選一個白天上班的時候提交審核，而不用等到半夜。
永遠需要立即響應
服務器端的問題，只要出現，影響都是巨大的，所以服務器端的同學需要隨時待命，一旦有服務器異常報警，就立即處理，以免影響到用戶。所以做服務器開發的同學手機都是開著的，在服務不穩定時，一不小心，幾十條報警短信就過來了。服務器開發出去旅遊什麼的，一般都帶著筆記本，以便出問題時能夠及時響應。
相對來說，客戶端同學在這方面要輕鬆得多，因為即使出現了 Bug，iOS 和 Android 客戶端也是無法馬上修復的，因為用戶手機中的版本不會立即更新。所以客戶端同學最多也是加班發佈一個緊急版本提交審核，在時間上不會像服務器端那麼著急。
另一方面，很多客戶端的 Bug，可以通過服務器端通過一些「兼容」來處理，這其實就是替客戶端「擦屁股」。例如，假設某應用的 iOS 1.2.0 版本當獲得服務器端返回的用戶頭象是 png 格式的時候會閃退，那麼服務器端可以特殊處理，對於這個版本的應用把 png 圖片轉成 jpg 返回。你看，最終還是服務器端同事成了要立即響應的人。
服務器端輪子太多
服務器端的開發經過了 10 多年的發展，而客戶端的開發才剛剛興起。2009 年 iPhone 3GS 推出之後，國內才有人做 iOS App 的開發，Android 開發的興起也基本在同一時期。算下來，客戶端的開發才經歷了 6 年而已。而服務器端的開發呢？光 Spring 就出現了 10 多年了。
服務器端的技術長久發展的結果就是，基本上每個業務需求都已經有現成的輪子了。所以做服務器端開發很多時候就是學習各種開源組件的用法，並且熟悉這些組件的一些性能特點和坑。
你以為這很容易嗎？其實不是的！這些輪子發展那麼多年，已經非常複雜了，光 Spring 就包括非常多的特性，寫一本 1000 頁的書來介紹它也不為過。如果不是多年的使用，你能搞明白它的各種功能的優缺點嗎？如果你搞不明白，遇到問題的時候除了抓瞎還能幹嘛？
所以做服務器端的同學，要經過非常長時間學習（至少半年左右），才能上手進行實際的開發工作。上手之後，又需要經過非常長時間的學習，才能夠熟悉自己使用的各種開源組件的特點和使用細節。
相對來說，客戶端同學在這方面要輕鬆得多，基本上不管是 iOS 還是 Android，新手只需要一個月左右就能入門，三個月左右就能夠比較熟練了。
分工與細化
剛剛說到服務器端複雜，這帶來的結果就是分工與細化。每個做服務器開發的同學，可能只會涉及服務器開發的某一部分的業務邏輯和功能，甚至是某一部分業務邏輯的某一層。比如我在網易郵箱做服務器端開發時，就只是負責 Restful Api 這一層的開發工作。
從業務上來說，將複雜的系統拆分，然後每個人做獨立的某一塊當然是好的。但是對個人來說，服務器端開發卻使終是一塊迷霧環繞的大山，在這座大山上，你對你走過的路線很熟悉，而那些你沒有接觸過的服務器端技術，你使終是不清楚的。
對於一個服務器端開發同學，特別是進入大公司的應屆生來說，在他頭幾年的工作中，肯定只會圍繞著非常小一塊功能業務來學習，那麼一兩年之後，他頂多是熟悉了他工作涉及的那些東西，對於別的東西仍然是不清楚的。
從這一點來說，去創業型的公司做服務器端開發又要比去大公司要好得多。
相對來說，客戶端同學在這方面要爽得多。因為移動開發技術剛剛興起，很多技術方案和框架還沒有複雜到無法全面掌握的程度。移動開發技術就像一棵快速成長的小樹，客戶端同學將有幸伴隨著它一起成長，等 5 年之後，移動開發技術成變成一棵參天大樹，這一代的程序員，將會是唯一親身經歷它演進的人，每一處演進帶來的改變，都將使得我們更加深刻理解移動開發系統的設計原則。
眼界和非技術成長
某種程度上說，服務器端開發在業務方面是輕鬆的，因為他們只需要設計好 API 接口，返回 JSON 數據，不用考慮 UI 的設計，交互細節的處理。服務器端開發經過了多年的發展，單元測試和性能測試框架也非常成熟，所以開發起來非常有章法。
所以服務器端的同學大多數時候只需要關注純技術的知識，例如如何保證高可用，高擴展性，高併發，數據一致性，數據安全等。
客戶端就苦了，UI 需要和美術設計得完全一樣，交互細節還需要做到流暢，很多時候產品用一用覺得一些 UI 和交互有問題，我們還需要被迫接受調整。另外在測試上，因為和界面耦合太緊，雖然業界有一些解決方案，但基本上不管是 iOS 和 Android 都還沒有非常成熟好用的單元測試框架。大部分的測試工作都是由黑盒的手工測試完成的。
但是，正因為客戶端需要密切和產品經理，UI 設計師打交道，所以他們會頻繁接觸到產品設計思想和設計思想。這使得客戶端的同學更加容易學習和積累編程之外的技能，包括產品和設計的思想以及溝通能力。另外，因為用戶的 bug 都是通過客戶端反饋，客戶端同學還更容易接觸到真實的用戶。
所以相對於服務器端同學來說，客戶端的同學的眼界更寬，由於非技術方面的溝通更多，所以他們的非技術方案的成長也越多。
技術挑戰和工資待遇
從純技術上的挑戰來說，服務器端明顯更大。服務器端開發動輒超過 10 人的團隊，代碼量稍微複雜一些就是接近百萬行。而客戶端一個平臺的研發大多數也就在 5 人左右，代碼量多在 10 萬行以內。
但是，技術挑戰大就表示工資待遇高嗎？NO！市場價格是由供求關係來平衡的。雖然客戶端的技術挑戰小，但是基本上所有應屆畢業生都想做服務器端開發，所以沒有人做客戶端開發呀！於是很多公司被迫從培訓機構招人，很多人剛剛培訓了 3 個月，就可以拿非常高的工資。這一點和 Web 前端類似，牛逼的 Web 前端人才非常少，但是不影響這個領域稍微牛逼一點的人拿非常高的薪水。
另一方面，由於服務器端人才的飽和，也使得競爭變得非常激烈，除非你成為這個領域的頂級人才，否則從平均薪資來說，做客戶端開發的同學應該和服務器端的同學類似。
總結
其實我這篇文章故意寫得很片面，目的就是想讓各位應屆生同學們能夠更加辯證地看待互聯網行業中的工作。與其什麼都不懂傻傻地選擇服務器端開發，倒不如做客戶端開發更有前途。
我以上所說的，都是錯的。
閱讀更多 一個程序員的奮鬥史 的文章
