在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

后端程序員的成長指南

工程師人生 ? 來源:簡書網 ? 作者:ThoughtWorks ? 2020-01-13 15:50 ? 次閱讀

開篇寄語 —— 彎道超車,為時未晚

前端領域如火如荼,工資水平也水漲船高。作為后端程序員的你,羨慕嗎?但羨慕是沒用的,更別提嫉妒恨了。古人曰:與其臨淵羨魚,不如退而結網。

接下來,我不但要教你結網,還要教你后端程序員彎道超車的秘訣。我將對前端領域的概念進行簡要說明,并盡量用后端領域的概念來作類比,受到筆者個人背景的限制,可能會更多使用Java世界的概念來進行類比,不過.net等世界也大同小異。

筆者就是從后端程序員轉型而來,深知阻撓后端程序員轉型的那些攔路虎。比如:陌生的工具鏈、陌生的語言、龐雜的W3C標準、不一樣的設計風格、不一樣的編碼風格等等,不過最大的攔路虎是……框架太多!每套框架都號稱自己有一系列優點,讓人眼花繚亂,無從抉擇。

事實上,對于前端程序員來說,在這些框架之間進行選擇確實很困難,因為有時候前端程序員會過于沉迷細節。比如,他/她可能在50毫秒和100毫秒的響應時間之間舉棋不定,可能會為了實現細節上的優點,而影響項目管理和可維護性。最嚴重的問題可能還在于:誤判了前端需求的增長速度和工程化開發的重要性,而這正是后端程序員們彎道超車的好時機。

細說從頭

以2004年Gmail的推出為起點,前端領域已經呈現出爆炸性增長的趨勢,經過十多年的成長,它是否即將進入停滯期?我只能說“Too young, too naive!”。在Web初興的時候,同樣有編寫傳統桌面應用的程序員覺得它會很快成長到停滯期,不過結果大家都已經看到了。在我看來,并不是什么“前端編程技術”橫空出世了,而是它的需求一直都存在,卻由于技術條件不足而被壓抑著 —— 直到Web技術成熟到能把它釋放出來,這才導致了前端橫空出世并急速膨脹的假象。

回憶一下,在“前端”的概念誕生之前,我們是怎樣實現一個Web應用的?我們會先在服務器上合成一段HTML,把它發回給瀏覽器;之后,幾乎任何操作都會向服務器發送一個請求,服務器再渲染一個完整的新頁面發回來。

跳出習慣性思維,反思一下:這是自然的嗎?我們為什么會需要如此復雜的過程?這其實是被迫做出的妥協:在從Netscape誕生開始的很長時間內,瀏覽器中的JS都是一個“玩具語言(這是JS之父說的)”:語法繁雜、坑多、解釋器性能低下、無模塊化機制、無成熟的工具鏈,無成熟的第三方庫等等,JS程序員(如果當時有的話)也毫無懸念的占據了鄙視鏈的底端。

面對JS這樣一位“豬隊友”,程序員們還能怎么辦?只能求助于萬能的服務端語言了:它幾乎不會受到瀏覽器的制約,可以自由使用所需的一切編程資源。幸運的是,Web技術的標準化工作在這個過程中得以蹣跚前行,而JS的標準化工作也在三大瀏覽器巨頭的博弈中艱難的前進著。

Chrome,特別是V8引擎的誕生,終于結束了JS解釋器的性能問題,更重要的是,基于V8引擎,誕生了偉大的NodeJS。NodeJS就是前端世界的JRE或.net CLR。它主要有三大貢獻:

讓JS語言“入侵”了后端世界和桌面世界。

這在前端開發的襁褓期有效擴大了JS語言的適用范圍,積累了大量第三方庫,很多第三方庫只要在合適的工具支持下也能在前端領域正常使用。

為前端開發提供了工具鏈。

如今的前端世界,其工具鏈的復雜度和完善度已經逐漸逼近后端世界,比如:類似于gradle的構建工具gulp、grunt,類似于maven的包管理工具npm,類似于junit的測試框架karma等等,它們無一例外,都是基于NodeJS的。

提供了標準化的模塊化方案CommonJS。

在NodeJS誕生之前,模塊化一直是JS世界的短板,雖然也有不少相互競爭的JS模塊化方案,卻都沒能一統江湖,這主要是因為當時的很多前端應用都過于簡單,對模塊化并沒有迫切需求。而隨著NodeJS入侵到后端世界和桌面世界,模塊化成了不得不做的事情,于是NodeJS內置的CommonJS就成為了事實性的標準。JS的最新版本ES6中內置的模塊化機制就是類似于CommonJS的。

與此同時,在另一條戰線上,還有一些技術在平行推進,那就是前端DOM庫與前端框架。在2006年,一個名叫jQuery的DOM庫橫空出世,它封裝了復雜的、特定于瀏覽器的DOM操縱類API,讓程序員可以不必處理一些繁瑣的細節差異,從而簡化了瀏覽器中的DOM編程。

在那個時代,雖然尚未正式提出“前端”的概念,不過已經出現了不少事實上的前端程序。但這些前端程序相對于如今包羅萬象的前端還是過于原始了,很多前端代碼都只是嵌入在后端頁面中的龍套。

不過,這些程序就像最早爬到岸上的魚一樣,帶人們發現了一個新世界,對前端程序的需求也隨之井噴。什么是“前端程序”呢?在我看來主要有如下幾個特征:

客戶端渲染

與傳統上借助后端生成新頁面的方式不同,前端程序借助瀏覽器的API來呈現內容(也就是“渲染”)并處理用戶動作,在這個過程中,并不需要借助服務端的運算能力,也不需要網絡

單頁面

客戶端渲染技術衍生出的一個主要特征是單頁面應用。因為不需要再由服務器發回新頁面,所以前端程序在理論上就具備了獨自渲染內容并全權處理用戶交互的能力,只在必要時,才會通過Web API尋求服務器的幫助。

實時反饋

客戶端渲染技術衍生出的另一個主要特征是實時反饋。在傳統的應用中,除非內嵌JS代碼,否則任何反饋都需要由服務端代碼生成并發回,而且編程相對復雜。這導致很少有程序能夠給出實時反饋,即使做到了實時反饋的,也會因為網絡延遲等問題而損害用戶體驗,而專業的前端程序則可以借助客戶端運算輕松實現實時反饋。

隨著技術的進步,前端終于具備了擺脫“石器時代”的條件,于是,前端的時代終于要開始了。

前端時代!

以jQuery為代表的DOM庫在使用中逐漸暴露出了很多缺點,特別是混雜邏輯代碼和操縱DOM的代碼導致難以維護。于是一大批新的前端MV*框架悄然出現了。

框架不同于庫:庫是一組被動式的代碼,如果你不調用它,它就什么都不做;而框架不同,框架提供了啟動、事件處理等各種通用性代碼,你按照框架規約寫自己的代碼,并把它“告訴”框架,框架會在合適的時機用合適的方式調用它們。

確實,這沒什么新鮮的,你早就用過Spring或asp.net了,不是嗎?從這一點上來說,前端框架與后端框架大同小異。不過,前端框架還是有自己的鮮明特色的:

它們是……用JS寫的。

毫無疑問,JS盡管并不完善,但它目前是并且仍將是前端世界的霸主,我認為其中最重要的原因是:它是各大瀏覽器廠商利益的最大公約數。Google曾孵化了一個在瀏覽器和后端共用的語言Dart,不過現在連自己的瀏覽器都不打算直接支持它了。從技術上講,Dart無疑是相當先進的,但現實卻更加殘酷。

它們是弱類型的。

受限于JS的能力,前端框架無法訪問運行時類型(就像Java或.net中的反射機制),也就無法像后端框架那樣大量借助接口來定義擴展方式。因此,框架只能借助一些復雜的技巧來達成目標。當然,后續的技術發展在一定程度上改變了這一點,那就是微軟的新語言TypeScript的誕生,我們稍后再展開這個話題

它們是靈活的。

得益于JS的動態特性和弱類型特性,前端框架也非常靈活,比如你可以把任意對象傳給調用者,只要這個對象有調用者所需的屬性或方法即可,而不用像Java那樣明確定義接口。靈活,是優點,也是缺點 —— 在小規模、需求穩定的程序中,它可以極大的提高開發速度,用過Ruby或者Python的程序員大概深有體會;但在大規模、需求頻繁變化的程序中,它將是BUG之源,用過Ruby或Python的程序員大概深有體會。

那些年,前端MV*庫的競爭,其激烈程度幾乎不下于各種語言的競爭。2009年,一個注定要名聲大噪的框架加入了這場前端MV*大戰,它叫Angular。

Hello, Angular!

Angular的英文原意是“角”,也就是“銳角、直角”的“角”。它的主要開發者Adobe Flex的開發者Misko以及很多來自Google的后端程序員,因此它有很多理念和概念來自于Flex和后端編程領域,如聲明式界面(Declarative UI)、服務(Service)、依賴注入(Dependency Injection)等,并為單元測試提供了優秀的支持。可以說,它天生就有后端基因,其設計目標也是處理像傳統后端一樣復雜的需求。幸運或者不幸的是,它仍然是一個前端框架。它具有高度的靈活性 —— 既可以寫得很規整,也可以寫得很爛。當然,在某種意義上,這不應該算作Angular的問題,而是JS的“原罪”。

這種情況意味著,如果有成熟的最佳實踐和優秀的開發規范,Angular程序可以寫得很漂亮:簡潔明了、模塊清晰、分層明確、關注點分離。但在開發組意識到社區需要一份來自官方的開發規范之前,Angular 0.x和1.x版本的爛代碼和壞習慣已經泛濫成災了。

幸運的是,Angular有一個繁榮、強大的社區,社區在行動。無論是英文社區還是中文社區,都出現了一些優秀的Angular工程師,他們總結出了一些經驗和教訓,并給出了自己的解決之道,全憑自己的力量與熱情在社區中傳播。如果你是一個后端程序員,會發現這些最佳實踐和開發規范似曾相識。沒錯,很多優秀的Angular工程師本來就是后端工程師出身。這并不奇怪,前端歲月尚淺,優秀的前端工程師當然會有很多是從優秀的后端工程師轉型而來的。

但這還不是根本原因。在有些人的思維中,前端和后端好像是兩個截然不同的世界。并非如此!編程之道本來就是互通的,并不存在前端的編程之道和后端的編程之道。主導這兩個開發領域的設計原則不外乎就是SOLID等少數幾個,無論是前端的編程規范還是后端的編程規范,都是對這些原則的實例化。

社區的努力,在一定程度上彌補了Angular早期版本的缺憾,但,這還不夠。我們需要一份官方的開發規范,甚至,一個更好的Angular。后者才是重點!

Hello, Angular 2!

優秀的框架特性、繁榮的社區、廣泛的應用,但都被ES5(JS的早期版本)這個豬隊友給拖累了,另一個豬隊友則是老版本瀏覽器 —— 特別是IE8及更低的版本。于是,就在Angular 1.x如日中天的時候,Angular開發組高調開始了新版本的開發工作,它就是Angular 2!這里還有很多小插曲按下不表,等我有時間開雜談時再慢慢說。

Angular 2本身不再是用ES5寫成的,而是TypeScript,簡稱TS。TS是微軟開發的一個新語言,它是ES6的超集,這意味著,凡是有效的ES6代碼都同樣是有效的TS代碼;另一方面,ES6是ES5的超集,所以凡是有效的ES5代碼也同樣是有效的TS代碼。但是在ES6的基礎上,TS增加了可選的類型系統以及在未來ES8中才會出現的裝飾器等特性。

你想知道TS為什么這么牛?很簡單,因為他爸是 —— 不,不,不是李剛,他爸是Anders Hejlsberg,如果Java程序員沒聽說過他還情有可原,如果是.net程序員,那就自己去面壁思過吧 —— 他是微軟.net的總架構師,C#語言之父,更資深的程序員可能還用過Delphi,那是Anders的“長子”。一個人設計了三個流行的工業級語言,也真是夠了。

雖然TS已經誕生了很久,但卻一直沒有流行起來,這主要是因為它還缺少一個“殺手級應用”。現在,Angular 2來了!

在擺脫了一個豬隊友之后,Angular 2終于可以隨心所欲的展示自己的風采了,比如:基于類型的依賴注入、強類型的庫文件、更加便捷的語法、標準化的模塊化機制等等,無法一一列舉。

但還有另一個豬隊友在拖后腿,那就是老式瀏覽器,對,說的就是你 —— IE 8!Angular從1.3開始就徹底拋棄了它,2.x就更不用說了。有一陣子,曾經傳言Angular 2不支持IE 11以下所有版本的IE,不過幸好,Angular開發組終于對現實做出了妥協,否則這又會是一個重大的公關危機了。能與IE 8說再見,真好。不過,這也意味著,當你準備開始用Angular 2做項目的時候,務必先跟客戶或產品經理敲定不需要支持IE 8,否則還是老老實實用Angular 1.2吧。

Angular 2,后端之友

在Angular 1中就從后端借鑒過很多概念,到Angular 2自然就更進一步了。這些概念對沒有做過后端開發的新前端來說會有一定的難度,不過對后端程序員來說這不過是小菜一碟。接下來我們就逐個講講。

服務與依賴注入

沒錯,它們跟后端的服務與依賴注入是同一個概念,只是在實現細節上略有不同:

后端的服務是一個單例,在Angular 2中同樣如此;

后端的服務是使用類型來注入的,在Angular 2中同樣如此,不過由于TS的限制,Angular 2中通常會根據類進行注入,而不是像傳統的后端程序那樣優先使用接口;

后端的依賴注入器是由框架提供的,Angular 2中同樣如此;

后端的依賴可以進行配置,Angular 2中同樣如此,不過它的配置方式更加靈活,它不需要單獨的配置文件(該死的XML),而是直接用程序代碼,這賦予了它額外的靈活性,卻幾乎沒有損失(這讓我想起了Grails)。

不過Angular 2的依賴注入體系比傳統的后端更加靈活,它是一棵由多個注入器組成的樹,這棵樹跟組件樹平行存在。你可以把局部使用的服務放在中下層節點上,來限制它的作用范圍,減小耦合度;你可以預留一些占位(Placeholder)服務,等待調用方實現它,以達到“用組合代替繼承”的效果(要了解詳情,請自行分析LocationStrategy的設計);可以在不同的層級上配置同一個類的不同依賴實例,這樣它就可以覆蓋掉上層的配置,在必要時臨時建立一個“獨立王國”。

可選強類型

強類型是很多Java程序員信心的保障,但同時也因為過于繁瑣而飽受抨擊。

現在,它隨著TS又來到了前端世界。不過不用害怕Java世界中的悲劇重演,因為TS中的強類型是“可選”強類型。這意味著你可以完全不定義變量、屬性、參數等的數據類型,TS編譯器也會照樣放行。當你需要快速建立一個原型時,這種特性會非常有用,因為你不用現在就做很多決策。但當有一天你的原型經歷了從產品經理到CEO的重重考驗,終于修成正果的時候,你會發現它“太爛”了。

這是好事,這說明你在開發過程中沒有浪費精力。但如果你想繼續像這樣把它發展成一個產品級應用,那就要悲劇了。因為代碼中有太多只有你自己知道的約定和隱式接口,但新過來和你進行合作開發的人是無法和你心靈相通的。用不了多久,本來就是一團面條的代碼就變成了一坨漿糊,然后你就開始了無止境的加班歲月。沒錯,“福兮禍之所依”,現實就是這么殘酷。

為了走得更遠,你先得為代碼中的變量、屬性、參數等標上數據類型、抽象出接口,并且基于它們建立相應的開發規范(最好能用持續集成(CI)工具進行保障)。有了這些,即使是兩個負情商的大老爺們兒也能輕松做到“心靈相通”了。

加完類型之后,你仿佛回到了自己所熟悉的后端領域。現在,你的地盤兒,你做主!

測試驅動開發

如果測試驅動開發還不是你的基本功,那可能說明你在后端開發方面還有短板。即使你不是想做全棧,而是想完全轉型成前端,也應該補習一下測試驅動開發的技能。因為未來的前端開發,即使在純邏輯類代碼的復雜度上都可能會趕上后端。

在1.x的時代,Angular就以其優秀的“可測試性”而著稱了,Angular 2當然不會放棄這個傳統優勢。Angular 2的單元測試更加簡單,我還是直說吧:Angular 2中單元測試的方式更像后端。在Angular 1.x的時代,單元測試中不得不使用諸如$controller(如果你不懂,請忽略它)等框架內部API,而Angular 2測試框架的設計中完全封裝了它們,當你測試一個組件時,大部分時候幾乎就是在測試一個普通的類。

傳統的前端程序員可能不太容易理解測試驅動開發的思維方式,特別是對于沒有什么后端經驗的資深前端。這也同樣是后端程序員實現彎道超車的好機會。隨著前端職責的加重,在前端代碼中,會出現越來越多的復雜邏輯,這些復雜邏輯如果沒有測試驅動開發的保障,將被迫用“寫代碼、切換到瀏覽器、界面上點點看看、切換回IDE”的低效循環進行開發。

更重要的是,它很容易誕生高度耦合、恰好能用的爛代碼。但在測試驅動開發的保障下,可以先從最簡單的規約開始,逐步補充更多規約。在開發過程中,你只要不時瞥一眼IDE的測試控制臺就可以了。這樣不但開發起來更快,而且可以收獲良好的代碼結構,因為容易測試的代碼通常也都是松耦合的。

分工,1+1 》 2

后端程序員學習前端技術時,往往會為HTML/CSS等頭疼不已,這些都是相對陌生甚至完全陌生的領域,如果急于為團隊貢獻生產力,那么請把這些“后背”交給你的隊友。

延續Angular的一貫傳統,Angular 2對團隊分工提供了卓越的支持,它通常會把一個界面分成模板(*.html、*.jade)、樣式(*.css、*.scss、*.less、*.styl)、組件(*.js、*.ts)和組件單元測試(*.spec.ts、*.spec.js)等幾個基本名(base name)相同的文件,它們被放在獨立文件中但能很好的相互協作。

當你的前端技能還在蹣跚學步的時候,請放心的寫下一些粗糙的HTML/CSS代碼,比如用div搭建出丑陋但能與你所寫的組件順暢協作的html文件。然后,提交它,等你的隊友幫你把它修成漂亮的產品級界面。同樣的,如果你的前端隊友還不太清楚該如何干凈漂亮的從組件中抽取出服務,那么你就可以放心的幫他/她修改組件代碼,而不用擔心無意間破壞了模板和樣式。

一個團隊中,如果能有謙遜的super star當然好,但這種團隊是可遇而不可求的,更現實的期望是一個能相互信任、各盡所能的團隊。而Angular在設計時就充分考慮了團隊分工的需求,要想建設這樣一個團隊,毫無疑問,Angular將是你的首選平臺!

結束語 —— Angular 2,全棧養成計劃

好吧,我承認我可恥的做了一次標題黨。本文并非在煽動后端程序員去革前端程序員的命,而是希望無論是前端程序員還是后端程序員,都能成長為優秀的全棧程序員(是的,前端程序員如果理解了Angular 2中的這些概念也會更容易向后端發展)。全棧程序員由于能有效節省溝通成本(比如不用頻繁協商API)而被很多開發組織寄予厚望,但真正培養起來可沒那么容易。

有一陣子,培養全棧程序員的期望被放在了Fullstack JavaScript上 —— 它既能寫前端程序又能寫后端程序還能寫桌面程序。不過事實證明,這種期望落空了。即使經過了大爆發,NodeJS在企業應用開發、大數據等領域的資源積累也遠遠不及Java、C#、Python,甚至將來還有被新崛起的Scala和Go超越的危險。

或許我們應該換一種思路了:全棧一定要用同一種語言寫前端和后端嗎?

并非如此。事實上,我們更應該看重的是編程模型、思維方式和協作模式等方面的復用,而語言層面只是細枝末節而已。所以,Java或C#,加上TS與Angular 2,給了培養全棧的新曙光。相似的概念模型、相似的思維方式、相似的協作模式,這才是全棧程序員真正的核心技能,與語言無關。

這些,才是Angular 2給專業開發團隊帶來的,最珍貴的禮物!

責任編輯:wv

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 程序員
    +關注

    關注

    4

    文章

    952

    瀏覽量

    29818
收藏 人收藏

    評論

    相關推薦

    TMS320C6000程序員指南

    電子發燒友網站提供《TMS320C6000程序員指南.pdf》資料免費下載
    發表于 12-24 17:19 ?0次下載
    TMS320C6000<b class='flag-5'>程序員</b><b class='flag-5'>指南</b>

    TMS320C55x DSP CPU程序員參考補充

    電子發燒友網站提供《TMS320C55x DSP CPU程序員參考補充.pdf》資料免費下載
    發表于 12-21 11:36 ?0次下載
    TMS320C55x DSP CPU<b class='flag-5'>程序員</b>參考補充

    UCD3138A64/UCD3138128程序員手冊

    電子發燒友網站提供《UCD3138A64/UCD3138128程序員手冊.pdf》資料免費下載
    發表于 12-09 14:42 ?0次下載
    UCD3138A64/UCD3138128<b class='flag-5'>程序員</b>手冊

    機械革命發布CODE AI程序員

    近日,英特爾新質生產力技術生態大會在成都舉行,機械革命作為重要參展商帶來了多款明星產品引爆全場!其中更是在AI PC軟件生態產品發布分論壇上,Intel、智譜、機械革命三方聯合發布了專為程序員設計的CODE AI程序員本,成為本次大會的一大亮點。
    的頭像 發表于 11-30 10:34 ?437次閱讀

    Linux驅動程序程序員指南

    電子發燒友網站提供《Linux驅動程序程序員指南.pdf》資料免費下載
    發表于 11-22 15:53 ?0次下載
    Linux驅動<b class='flag-5'>程序</b><b class='flag-5'>程序員</b><b class='flag-5'>指南</b>

    AI編程工具會不會搶程序員飯碗

    AI編程工具可輔助編程,減少手動編碼,提升效率,對程序員有積極影響也有挑戰。程序員需深化技能、拓寬知識應對。長遠看,AI與人類程序員將共生共榮。
    的頭像 發表于 11-08 10:17 ?187次閱讀

    第五屆長沙·中國1024程序員節開幕

    據官方媒體報道,10月24日;? 第五屆長沙·中國1024程序員節在湖南湘江新區開幕;本次中國1024程序員節以“智能應用新生態”為主題。設置有岳麓對話、技術英雄會、主題峰會及賽事、展覽等活動,一場
    的頭像 發表于 10-25 15:42 ?213次閱讀

    90后程序員的職業成長漫談

    作者:京東零售 盧楠 前言: 我在京東工作已經來到第8個年頭,從2016年的實習生到如今負責部門整體架構,這段職業旅程中充滿了感悟。 簡單回顧我的個人成長里程碑:2017年正式加入京東后,從一名新人
    的頭像 發表于 10-15 15:24 ?175次閱讀
    90后<b class='flag-5'>程序員</b>的職業<b class='flag-5'>成長</b>漫談

    程序員節視頻創意大賽,用串口屏贏取千元大獎

    10月24日,程序員專屬的節日里,我們盛大開啟“程序員節視頻創意大賽”特別活動!這不僅是一場視覺的盛宴,更是智慧與創意的璀璨碰撞。我們誠摯邀請每一位程序員及編程愛好者,拿起你的鏡頭,記錄下那些平凡日子中的不凡瞬間,讓編程的魅力與
    的頭像 發表于 07-08 10:38 ?72次閱讀
    <b class='flag-5'>程序員</b>節視頻創意大賽,用串口屏贏取千元大獎

    程序員節視頻創意盛宴,邀您共襄盛舉!

    10月24日,程序員專屬的節日里,我們盛大開啟“程序員節視頻創意大賽”特別活動!這不僅是一場視覺的盛宴,更是智慧與創意的璀璨碰撞。我們誠摯邀請每一位程序員及編程愛好者,拿起你的鏡頭,記錄下那些平凡日子中的不凡瞬間,讓編程的魅力與
    的頭像 發表于 07-04 09:00 ?67次閱讀
    <b class='flag-5'>程序員</b>節視頻創意盛宴,邀您共襄盛舉!

    適者生存,程序員最終會流向哪……

    程序員沒有永遠的護城河!!就目前的互聯網大環境來看,it行業已經是……
    的頭像 發表于 03-11 17:11 ?420次閱讀
    適者生存,<b class='flag-5'>程序員</b>最終會流向哪……

    薪資高、青春飯,是不是程序員=青樓?

    花期太短。技術迭代快,年齡大容易失業。 就這幾年的互聯網環境而言,不管是前端、Java、Android開發等等行業。已經感受到程序員不是太卷就是工作難找,薪資過低。以前高工現在拿著中低程序員薪資
    發表于 03-06 21:32

    瑞薩Flash程序員V3 發布說明

    電子發燒友網站提供《瑞薩Flash程序員V3 發布說明.pdf》資料免費下載
    發表于 02-19 09:37 ?1次下載
    瑞薩Flash<b class='flag-5'>程序員</b>V3 發布說明

    2024程序員的未來方向如何走?還看今朝

    這幾年的IT行業想必大家已經感受到了,Android、Java、前端等等程序員都經歷了大廠……
    的頭像 發表于 02-02 09:45 ?839次閱讀
    2024<b class='flag-5'>程序員</b>的未來方向如何走?還看今朝

    1月18號“純鴻蒙”千帆啟航,程序員預備!

    。 如何正確看待鴻蒙? 我作為程序員來說,首先是看鴻蒙的發展、市場開發崗位、薪資以及前景。 這幾年對鴻蒙的發展情況來分析,從2019年開始鴻蒙的出來今天,華為鴻蒙取得了很大的成就。從“不兼容
    發表于 01-16 22:13
    主站蜘蛛池模板: yyy6080韩国三级理论| 免费大秀视频在线播放| 日日摸夜夜添免费毛片小说| 久久这里只有精品任你色| 性感美女视频黄.免费网站| 在线理论视频| 久久男人的天堂色偷偷| 四虎8848精品永久在线观看| 美女扒开尿口让男生添 漫画| 1024手机看片国产| 日本激情网| 天天躁天天狠天天透| www.毛片网站| 国产欧美乱码在线看| 人人澡人人草| 四虎影院新地址| 五月天婷婷一区二区三区久久| lsj老司机精品视频在线观看| 亚洲视频一区二区| 久久伊人草| 欧美性猛交xxxx黑人猛交| 国产精品色片| 奇米9999| 日操夜干| 欧美性狂猛bbbbbbxxxx| 美女下面小内内的沟| 添人人躁日日躁夜夜躁夜夜揉| 亚洲 欧美 自拍 另类| 在线播放免费视频| 人人天天夜夜| xxxx欧美xxxx黑人| 91免费在线视频| 成人aaa| 妇女交性大片| 色爽视频| 日韩在线三级视频| 日本久久高清视频| 欧美日韩不卡码一区二区三区| 人与牲动交xxxxbbbb高清| 国产一卡二卡3卡4卡四卡在线| 国产女主播精品大秀系列在线|