前言

猿題庫剛剛結(jié)束了北京地區(qū)的大規(guī)模校園招聘，國慶之后打算轉(zhuǎn)戰(zhàn)外地進(jìn)行校招。我本人深度參與了此次的校招工作，包括筆試題***、面試題***以及具體的面試工作。

[[152111]]

我在面試中發(fā)現(xiàn)了一個非常有意思的現(xiàn)象，就是大多數(shù)應(yīng)屆生都想做服務(wù)器端開發(fā)，但是他們卻又不清楚服務(wù)器端開發(fā)具體要做些什么。

我和同事聊天的時候說起此事，我們認(rèn)為可能應(yīng)屆生覺得：做服務(wù)器端開發(fā)可以讓自己寫的程序運行在很多臺機器上，并且處理海量的數(shù)據(jù)，這很「牛逼」。而做客戶端或前端開發(fā)太簡單，成長會比較小。

于是我就寫了本文，想給這些單純的應(yīng)屆生潑潑冷水。先說說我的背景吧，我同時做過服務(wù)器端和客戶端的開發(fā)。我在網(wǎng)易有道做過 1 年半的服務(wù)器端開發(fā)，產(chǎn)品涉及網(wǎng)易郵箱和微博產(chǎn)品，之后做了 3 年的 iOS 開發(fā)，產(chǎn)品涉及有道云筆記，猿題庫和小猿搜題，所以我能夠給大家分享服務(wù)器端和客戶端開發(fā)的差別。

對服務(wù)器開發(fā)的誤解

很多應(yīng)屆生認(rèn)為做服務(wù)器端開發(fā)可以處理海量數(shù)據(jù)，管理上百臺服務(wù)器。

但是 ——

處理海量數(shù)據(jù)就牛逼了?NO!

服務(wù)器端開發(fā)經(jīng)過多年的發(fā)展，對于海量數(shù)據(jù)的處理早有了很多固定的解決方案。不管是用云服務(wù)，還是用 Hbase ，你都可以很輕松地依賴開源庫，解決海量數(shù)據(jù)的存儲問題。

還有一些同學(xué)想做大數(shù)據(jù)分析，如果你寫過 MapReduce 程序就不會這么想了。現(xiàn)在的 MapReduce 程序?qū)懫饋硖?easy 了，很多時候簡單到你就只需要寫一條類似 SQL 的查詢就行了。

運行在上百臺服務(wù)器上就牛逼了?NO!

現(xiàn)在虛擬化技術(shù)發(fā)展迅猛，像小猿搜題所有服務(wù)都通過 Docker 來部署。很多時候，部署上線就是在 Web 管理界面上點擊一個「Deploy」按鈕即可。即使在過去，實際操作這些上百臺服務(wù)器的也是運維同學(xué)，輪不到你來操作。

所以，除了 YY 一下這些程序跑在多個機器上，這并沒有什么可以帶來成就感的地方。

還有一些應(yīng)屆生覺得自己在學(xué)校做過網(wǎng)站，覺得在服務(wù)器開發(fā)方面有基礎(chǔ)，做這方面更順手。NO!企業(yè)里面的服務(wù)器開發(fā)完全不是你想的那樣，基本上大家在學(xué)校做網(wǎng)站的經(jīng)驗等于零。

服務(wù)器開發(fā)的苦

我給大家分享一下做服務(wù)器開發(fā)有什么苦的地方吧。

永遠(yuǎn)只能半夜上線

做為互聯(lián)網(wǎng)公司，我們希望給用戶提供 7 x 24 的不間斷服務(wù)，那么服務(wù)萬一需要中斷怎么辦?半夜上線唄。

根據(jù)我多年的觀察，晚上 12 點一般都是上網(wǎng)高峰，所以上線一般都是凌晨 3 點-4 點的時候進(jìn)行。但是，你以為上線就是凌晨 3 點點一下「Deploy」按鈕就完了嗎?NO! 一般上線都會涉及功能升級，難免會有考慮不周到的情況，于是就會發(fā)生，上線出問題的情況。

上線出問題怎么辦?在網(wǎng)易，我們一般是兩種做法：

在線調(diào)試和修改 Bug，通常順利的話，到早上 7，8 點的時候一般就能搞定了。

在線調(diào)試和修改 Bug，如果不順利的話，到早上 7，8 點的時候回滾數(shù)據(jù)。然后，我們需要回家休息半天之后，繼續(xù)在下一個凌晨 3 點上線。

當(dāng)然，不會每次上線都是這種大升級，但是基本上，1、2 個月搞一次這種大上線還是挺常見的。

相對來說，客戶端同學(xué)在這方面要輕松得多。iOS 和 Android 都是提交應(yīng)用市場審核，所以客戶端的同學(xué)可以選一個白天上班的時候提交審核，而不用等到半夜。

永遠(yuǎn)需要立即響應(yīng)

服務(wù)器端的問題，只要出現(xiàn)，影響都是巨大的，所以服務(wù)器端的同學(xué)需要隨時待命，一旦有服務(wù)器異常報警，就立即處理，以免影響到用戶。所以做服務(wù)器開發(fā)的同學(xué)手機都是開著的，在服務(wù)不穩(wěn)定時，一不小心，幾十條報警短信就過來了。服務(wù)器開發(fā)出去旅游什么的，一般都帶著筆記本，以便出問題時能夠及時響應(yīng)。

相對來說，客戶端同學(xué)在這方面要輕松得多，因為即使出現(xiàn)了 Bug，iOS 和 Android 客戶端也是無法馬上修復(fù)的，因為用戶手機中的版本不會立即更新。所以客戶端同學(xué)最多也是加班發(fā)布一個緊急版本提交審核，在時間上不會像服務(wù)器端那么著急。

另一方面，很多客戶端的 Bug，可以通過服務(wù)器端通過一些「兼容」來處理，這其實就是替客戶端「擦屁股」。例如，假設(shè)某應(yīng)用的 iOS 1.2.0 版本當(dāng)獲得服務(wù)器端返回的用戶頭象是 png 格式的時候會閃退，那么服務(wù)器端可以特殊處理，對于這個版本的應(yīng)用把 png 圖片轉(zhuǎn)成 jpg 返回。你看，最終還是服務(wù)器端同事成了要立即響應(yīng)的人。

服務(wù)器端輪子太多

服務(wù)器端的開發(fā)經(jīng)過了 10 多年的發(fā)展，而客戶端的開發(fā)才剛剛興起。2009 年 iPhone 3GS 推出之后，國內(nèi)才有人做 iOS App 的開發(fā)，Android 開發(fā)的興起也基本在同一時期。算下來，客戶端的開發(fā)才經(jīng)歷了 6 年而已。而服務(wù)器端的開發(fā)呢?光 Spring 就出現(xiàn)了 10 多年了。

服務(wù)器端的技術(shù)長久發(fā)展的結(jié)果就是，基本上每個業(yè)務(wù)需求都已經(jīng)有現(xiàn)成的輪子了。所以做服務(wù)器端開發(fā)很多時候就是學(xué)習(xí)各種開源組件的用法，并且熟悉這些組件的一些性能特點和坑。

你以為這很容易嗎?其實不是的!這些輪子發(fā)展那么多年，已經(jīng)非常復(fù)雜了，光 Spring 就包括非常多的特性，寫一本 1000 頁的書來介紹它也不為過。如果不是多年的使用，你能搞明白它的各種功能的優(yōu)缺點嗎?如果你搞不明白，遇到問題的時候除了抓瞎還能干嘛?

所以做服務(wù)器端的同學(xué)，要經(jīng)過非常長時間學(xué)習(xí)(至少半年左右)，才能上手進(jìn)行實際的開發(fā)工作。上手之后，又需要經(jīng)過非常長時間的學(xué)習(xí)，才能夠熟悉自己使用的各種開源組件的特點和使用細(xì)節(jié)。

相對來說，客戶端同學(xué)在這方面要輕松得多，基本上不管是 iOS 還是 Android，新手只需要一個月左右就能入門，三個月左右就能夠比較熟練了。

分工與細(xì)化

剛剛說到服務(wù)器端復(fù)雜，這帶來的結(jié)果就是分工與細(xì)化。每個做服務(wù)器開發(fā)的同學(xué)，可能只會涉及服務(wù)器開發(fā)的某一部分的業(yè)務(wù)邏輯和功能，甚至是某一部分業(yè)務(wù)邏輯的某一層。比如我在網(wǎng)易郵箱做服務(wù)器端開發(fā)時，就只是負(fù)責(zé) Restful Api 這一層的開發(fā)工作。

從業(yè)務(wù)上來說，將復(fù)雜的系統(tǒng)拆分，然后每個人做獨立的某一塊當(dāng)然是好的。但是對個人來說，服務(wù)器端開發(fā)卻使終是一塊迷霧環(huán)繞的大山，在這座大山上，你對你走過的路線很熟悉，而那些你沒有接觸過的服務(wù)器端技術(shù)，你使終是不清楚的。

對于一個服務(wù)器端開發(fā)同學(xué)，特別是進(jìn)入大公司的應(yīng)屆生來說，在他頭幾年的工作中，肯定只會圍繞著非常小一塊功能業(yè)務(wù)來學(xué)習(xí)，那么一兩年之后，他頂多是熟悉了他工作涉及的那些東西，對于別的東西仍然是不清楚的。

從這一點來說，去創(chuàng)業(yè)型的公司做服務(wù)器端開發(fā)又要比去大公司要好得多。

相對來說，客戶端同學(xué)在這方面要爽得多。因為移動開發(fā)技術(shù)剛剛興起，很多技術(shù)方案和框架還沒有復(fù)雜到無法全面掌握的程度。移動開發(fā)技術(shù)就像一棵快速成長的小樹，客戶端同學(xué)將有幸伴隨著它一起成長，等 5 年之后，移動開發(fā)技術(shù)成變成一棵參天大樹，這一代的程序員，將會是***親身經(jīng)歷它演進(jìn)的人，每一處演進(jìn)帶來的改變，都將使得我們更加深刻理解移動開發(fā)系統(tǒng)的設(shè)計原則。

眼界和非技術(shù)成長

某種程度上說，服務(wù)器端開發(fā)在業(yè)務(wù)方面是輕松的，因為他們只需要設(shè)計好 API 接口，返回 JSON 數(shù)據(jù)，不用考慮 UI 的設(shè)計，交互細(xì)節(jié)的處理。服務(wù)器端開發(fā)經(jīng)過了多年的發(fā)展，單元測試和性能測試框架也非常成熟，所以開發(fā)起來非常有章法。

所以服務(wù)器端的同學(xué)大多數(shù)時候只需要關(guān)注純技術(shù)的知識，例如如何保證高可用，高擴展性，高并發(fā)，數(shù)據(jù)一致性，數(shù)據(jù)安全等。

客戶端就苦了，UI 需要和美術(shù)設(shè)計得完全一樣，交互細(xì)節(jié)還需要做到流暢，很多時候產(chǎn)品用一用覺得一些 UI 和交互有問題，我們還需要被迫接受調(diào)整。另外在測試上，因為和界面耦合太緊，雖然業(yè)界有一些解決方案，但基本上不管是 iOS 和 Android 都還沒有非常成熟好用的單元測試框架。大部分的測試工作都是由黑盒的手工測試完成的。

但是，正因為客戶端需要密切和產(chǎn)品經(jīng)理，UI 設(shè)計師打交道，所以他們會頻繁接觸到產(chǎn)品設(shè)計思想和設(shè)計思想。這使得客戶端的同學(xué)更加容易學(xué)習(xí)和積累編程之外的技能，包括產(chǎn)品和設(shè)計的思想以及溝通能力。另外，因為用戶的 bug 都是通過客戶端反饋，客戶端同學(xué)還更容易接觸到真實的用戶。

所以相對于服務(wù)器端同學(xué)來說，客戶端的同學(xué)的眼界更寬，由于非技術(shù)方面的溝通更多，所以他們的非技術(shù)方案的成長也越多。

技術(shù)挑戰(zhàn)和工資待遇

從純技術(shù)上的挑戰(zhàn)來說，服務(wù)器端明顯更大。服務(wù)器端開發(fā)動輒超過 10 人的團隊，代碼量稍微復(fù)雜一些就是接近百萬行。而客戶端一個平臺的研發(fā)大多數(shù)也就在 5 人左右，代碼量多在 10 萬行以內(nèi)。

但是，技術(shù)挑戰(zhàn)大就表示工資待遇高嗎?NO!市場價格是由供求關(guān)系來平衡的。雖然客戶端的技術(shù)挑戰(zhàn)小，但是基本上所有應(yīng)屆畢業(yè)生都想做服務(wù)器端開發(fā)，所以沒有人做客戶端開發(fā)呀!于是很多公司被迫從培訓(xùn)機構(gòu)招人，很多人剛剛培訓(xùn)了 3 個月，就可以拿非常高的工資。這一點和 Web 前端類似，牛逼的 Web 前端人才非常少，但是不影響這個領(lǐng)域稍微牛逼一點的人拿非常高的薪水。

另一方面，由于服務(wù)器端人才的飽和，也使得競爭變得非常激烈，除非你成為這個領(lǐng)域的***人才，否則從平均薪資來說，做客戶端開發(fā)的同學(xué)應(yīng)該和服務(wù)器端的同學(xué)類似。

總結(jié)

其實我這篇文章故意寫得很片面，目的就是想讓各位應(yīng)屆生同學(xué)們能夠更加辯證地看待互聯(lián)網(wǎng)行業(yè)中的工作。與其什么都不懂傻傻地選擇服務(wù)器端開發(fā)，倒不如做客戶端開發(fā)更有前途。

我以上所說的，都是錯的。

博文出處：http://blog.devtang.com/blog/2015/10/07/why-fresh-wants-to-do-server-dev/