隨筆：寫前端代碼與作後臺開發的區別以及將來職業規劃的思考

1、寫前端代碼和對前端開發人員將來職業規劃的思考

爲何我用「寫」前端「代碼」，由於在前端真的是在「寫代碼」而非「作開發」。

我在以前的公司從實習生開始一直是作Java後臺的開發，再以前的公司實習也是Java後臺，前先後後的後臺經歷累計有3年多（中間有996加班哦）。

由於「機緣巧合」——前端開發「跑路了」，本着一樣是Java語言的本家，讓我臨時頂替Android開發的職位，同時還要承擔一些Java後臺的維護任務。

再後來，趕鴨子上架，被迫去研究H5（捂臉，當時內心真的怕怕的，忐忑不安）

一開始自學前端的時候仍是挺有意思的，前端與後臺不一樣，很形象。好比寫個組件立馬在真機上跑一下，能夠看到顯示效果，還有手勢、點按、拖拽等的動畫效果。

但是常常爲了顯示效果好看，要調整代碼N遍，爲了適配各類坑爹機型 ＝_＝＃

前端對複雜數據處理和邏輯判斷很少，基本上都在後臺作。

由於前端計算的數據最多隻是顯示，後臺不可能依賴前端的計算返回的數據去入庫的。

好比：以前開發過一個App擁有地圖LBS的內容，實際上是在Android本地載入了一個地圖數據包，前端要作的事情就是顯示一張區域大地圖，獲取用戶在屏幕上點按事件的參數——「屏幕位置」（左上角開始的XY軸），轉換計算成圖片的像素位置（一個軸位等於幾個像素是根據圖片被用戶放大的倍數來計算），再去地圖數據包裏查詢像素位置，獲得用戶點按的區域叫什麼名字，如「徐家彙地鐵站」等，在這個區域上「插上小鏢旗」是調用圖像繪製方法在屏幕上畫圖。或者，調用系統的GPRS接口得到經緯度的參數，去地圖數據包裏查詢，以後和前面同樣「插上小鏢旗」。

在這過程當中前端只負責：顯示地圖，獲取觸點數據，查詢本地地圖數據包，畫圖。接下來要得到用戶點按後選定的地點之間的導航路徑，就得向後臺發送查詢。

由此看出，前端更專一於，「顯示」－「獲取」－「反饋」，這三個與用戶交互的層面。

而從前端的開發語言和框架的發展歷史上也能看出是順應這個路線軌跡的。

好比：Android和iOS自各都會更新顯示組件，變得與用戶的交互體驗愈來愈好，程序員調用和增長本身想要的效果愈來愈方便，例如：最新的AR／VR。

甚至還出現了入門更加簡單的語言：Swift（iOS）、Kotlin（Android）。

而前端的代碼在需求改變時被整個推倒重來的機率是99%，因此真的是「寫代碼」而不是「作開發」，說多了都是淚！

這裏插入一下編程語言的發展規律介紹：

我在一開始學寫代碼的時候（大約十二年前，剛剛擁有一臺很破的電腦能夠上網，不能關機，只能休眠，不然開不了機的那種，😓）

夢想有一天能夠本身創造出一門編程語言。爲此，大學裏的「編譯」這門課是我自學課程裏成績最好噠（此處應有掌聲👏👏👏）

但是，當我踏上工做崗位時發現，創造一門語言簡單，可是要有人來用卻很是複雜。

1. 語言須要定位

好比：

Java一開始解決不一樣平臺的移植問題，創造了JVM虛擬機的概念，此後還順應時勢和自然跨平臺優點推出了EE、SE、ME等。在服務器、桌面、移動等領域大展拳腳、吸引許多開發者爲之貢獻出本身積累的代碼、迭代演化成框架。

C++更專一於底層的靈活調用，不像Java那樣耗費內存，更適合於圖形學、圖像處理、數據處理等浮點數計算的場景。（在GPU、顯存價格很高的年代劇有非凡意義）

R語言的各類統計學計算公式現成方法，調用處理數據很是方便。

Python定位爲腳本，方便易用，功能強大，「人生苦短、我用Python」。

C# 微軟的「語法糖」系列之一，與微軟本身的產品結合緊密，常常能夠一體化完成全部功能。（以前的公司有.Net開發團隊，有幸去幫過忙，接觸過一段時間）

JavaScript 跟Java不是一家人，是Netscape公司爲了自家的瀏覽器推出的前端腳本語言，後被各大瀏覽器接受稱爲W3C標準之一。（微軟還破壞W3C的標準，54安全隱患，給JS增長了不少「語法糖」，以此吸引並下降前端開發者門檻，惡劣競爭排擠其餘瀏覽器——能在IE上跑的JS「語法糖」代碼在其餘瀏覽器上會失效，因此不少網站都註明必須使用IE，其中銀行類網站是重災區⭐️_⭐️！）

2. 框架須要維護

好比：

前端JS的框架多如牛毛，各類前端效果、DOM操控、設計模式。github上90%以上的JS代碼是重複的。

後臺Java框架跨遍各大領域，在服務器端百花齊放，微服務、路由、消息等等。開源、維護廠商衆多。

一門語言不僅僅是語法體系成熟，更重要的是擁有衆多使用者積累出來的框架，使得新手擁有衆多框架資產可供選擇使用，語言才能存活。

3. 是否依賴硬件

一門語言的誕生可能只是解決某個問題，出於某種目的。

前端的編程語言高度依賴硬件，舉個🌰：

一開始的智能手機內存和CPU都比較差，要顯示一些複雜的圖形效果很是困難，屏幕獲取的精度也不高，前端開發人員能作的事情不多。

但隨着硬件設備的更新換代速度如此之高（感謝果粉的腎），前端的功能也愈來愈多，可是前端的開發語言卻愈來愈簡單，不少功能直接一個現成系統接口調用搞定，這是爲何呢？

緣由是，硬件廠商都有本身的競爭法則，硬件高端和低端產品升級都有本身的規劃路線，而其中依賴於硬件性能和功能的編程語言就會隨着硬件廠商的規劃而變化（注意：不是發展而是跟着變化，是被動的）。

所以，硬件廠商爲了擴大市場佔有率，但願大量開發者能使用本身的開發語言，會千方百計下降本身開發語言的門檻，吸引更多的開發者和新手（Swift（iOS）、Kotlin（Android）都是出於這個目的）。當市場上某種語言的開發者佔多數時，作軟件的公司招人成本會下降，更容易找到適合的人，更願意爲其硬件開發App等，使得此硬件的用戶量頗高，造成良性循環。

幾大廠商亦是如此：

微軟自身不出產手機，爲了擴大本身.Net在移動端的地位，聯合Nokia推廣本身的WinPhone系列，依然走「語法糖」路線，可是諾基亞原本的塞班系統體驗很好，開發者羣體也穩定，加之諾基亞集團的內部矛盾，還曾出現過一個短命的OS meego，最終致使Nokia在智能機時代的覆滅。

因爲Android內核的開源性，Google 摩托羅拉、三星、華爲、小米等廠商各自爲本身的硬件打造最適合的Android系統，Google領頭作開發框架的統一規劃，下降新手開發難度。

iOS的蘋果就不用說了，高大上的開發工具、豐富的組件、標準化的機型、內部生態圈體系，無疑吸引着全球開發者渴望的眼球。

JS語言依賴瀏覽器、W3C標準。

後臺開發語言依賴操做系統，.Net至今還未對Linux拋出繡球，Java在Win系和Linux等支持良好。

4. 支持的IDE

一門語言要存活併發揚光大，除了以上幾點，還有要對開發人員友好，美麗的IDE和豐富的懶人插件是必不可少的。

這裏有點扯遠了，爲何要說這些？

由於前端人員的職業規劃很是依賴其語言的發展，從橫向提及，爲了擴展生存能力和技能維度，前端人員能夠橫跨Android、iOS、WinPhone，精通JS作H5和Hybrid，還有PHP（傳說中最好的語言，論壇奇蹟，不懂自行google知），甚至學學Node.js作一個僞後臺開發。從縱向深刻拓展，能夠了解某個移動硬件操做系統的核心（Android是開源的，蘋果就比較悲劇，但最可憐的是.Net的開發人員），瞭解JS賴以生存的瀏覽器、解析器等。但這些都基於幾大硬件廠商的態度，他們爲了擴大自身的佔有率，下降開發門檻，致使大量新人涌入，形成2～3年的開發者在以後的職業發展上被新人輕易取代的悲劇。由於在前端，新的框架一出現，每每學習成本上，新人和有資歷的老人是同樣的。而前端開發人員往縱向深刻拓展時，就須要不斷跳槽，在須要你更高技能的公司擔任要職，大部分普通的軟件公司對前端的需求技能要求並不高。

這樣就產生了一個矛盾，對高端職位的需求又不會很大，造成過個幾年前端人員的晉升面臨僧多粥少的局面。因此，很多前端開發人員另找出路，轉型作產品經理、UI、UE、UX的也很多。

2、作後臺開發和對架構師將來職業規劃的思考

在後臺「作開發」的路徑曲折而悠長，一開始的SSH框架、MVC設計模式，帶你入門 ，在大學課程裏學習的數據庫、數據結構、面向對象設計、高數知識、網絡原理、編譯原理等知識都派上用場（而在前端就...😄）

在洗禮完了這麼多知識和實踐應用過程後，會對各類開發框架和設計模式有所認識，對技術架構有所瞭解，專一於數據庫方面的對數據架構很有感慨，趁着大數據的東風翱翔。而若是是在甲方的話，就能上升到應用架構和業務架構的層次，還有企業架構EA。

後臺好玩的東西特別多，並且和業務聯繫很是緊密（前端是和需求聯繫緊密，和業務真沒啥大關係，個人感受）。

最先，我作的實習項目是給電視臺搭建抽獎平臺，總體平臺設計很是複雜，各類消息控制，我在其中寫了一段定時更新消息的模塊。

後來，參與了幾個ERP系統，作供應鏈管理的，都是大型集團內部使用，或對客戶下單的，基本上以MVC爲主。

其中，對客戶和對管理都有兩套系統體系，系統之間業務架構設計和數據架構特別有趣（當時在乙方，涉及某些機密這裏不能多說）。

再後來到了金融行業，隨着電商行業大發展，架構上有SOA，通訊上有RESTful API、各類消息組件、智能營銷大數據。還有幸知道並參與了一種叫作「1+1+N」的銀行架構（望天ing，仰望➕崇拜）的建設（在其中搬磚）

這裏插一個對安全的思考

應用層的安全在前端和後臺通訊加密方面比較着重且被研究衆多（連量子計算都來湊熱鬧了），在作Android的SDK不被篡改方面借鑑了移動遊戲的更新包技術（具體咋作的保密），然後臺的業務邏輯安全真的很是複雜。

不但涉及到業務邏輯的設計，更重要的是在開發過程當中進行跟蹤和管理。不少時候業務邏輯的設計只是正向的，符合正常人的思惟方式，不會去過多涉及黑客的思想。而開發人員在拿到概要設計開始規劃模塊時，也是思考實現這些功能，而非作過多控制和防禦。這就致使，模塊與模塊、功能和功能之間的控制差別，一些權限的全局控制，信息流的傳遞過程直至最終入庫是否被篡改等，都有着許多隱患。

並且在跨幾個系統之間信息傳遞和校驗控制上很容易出現問題，每每越日後面的系統越不知道前面的系統到底幹了啥，只會根據現有的業務邏輯去作開發，不會考慮是否存在總體的業務邏輯漏洞。

因此，爲了解決這些問題，在最前一層，也就是暴露給前端調用的接口設計上，必須儘可能簡潔，一個接口就是一個簡單的功能，不能由於參數差很少就幾個功能複用一個接口，要防止黑客經過多餘的參數篡改達到繞過校驗控制的目的。在提供出去的API接口上，最好作後臺SDK進行封裝，不能把複雜業務邏輯都拋出去直接給外部調用，以防止黑客利用接口之間調用邏輯的調換和參數的巧妙移花接木達到破壞的目的。

扯回來繼續說後臺！

後臺，真的是「作開發」，每每親自寫的代碼並很少（IDE太聰明啦，自動填上代碼），更多的是集中在模塊的規劃，功能的實現方式（數據庫過於強大啦，能丟給數據庫作的絕對不要本身寫代碼，給本身挖坑），調用方法的邏輯層次上。

往橫向考慮能夠作技術架構，瞭解各類技術：Java框架、數據庫、通訊組件、SOA等。

往縱向考慮能夠作某一領域的專家，好比專門作電商的、金融的、ERP等，成爲某種業務領域的應用架構專家或數據架構專家。

對業務很是熟的能夠作業務架構，甚至作企業架構。（在作業務的那段時間裏，感受到業務的深奧，逼迫你不斷學習各類知識，MBA、FRM、CFA、營銷學等，還好有點會計基礎）

P.S. 下次再說說本身的研究和對遊戲開發的見解😊