一、寫前端代碼和對前端開發人員未來職業規划的思考
為什么我用“寫”前端“代碼”，因為在前端真的是在“寫代碼”而非“做開發”。
我在之前的公司從實習生開始一直是做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的也不少。
二、做后台開發和對架構師未來職業規划的思考
在后台“做開發”的路徑曲折而悠長，一開始的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. 下次再說說自己的研究和對游戲開發的看法😊