程序員是做前端開發(fā)好，還是后端開發(fā)好呢？程序員的概念在當(dāng)今社會(huì)非常普遍。它是時(shí)代創(chuàng)造的，也是一種潮流。科學(xué)技術(shù)是第一生產(chǎn)力，因?yàn)檫@個(gè)職業(yè)包含了這個(gè)社會(huì)太多人的技能，而不僅僅是代碼編寫、思維能力、行為模

程序員是做前端開發(fā)好，還是后端開發(fā)好呢？

程序員的概念在當(dāng)今社會(huì)非常普遍。它是時(shí)代創(chuàng)造的，也是一種潮流。科學(xué)技術(shù)是第一生產(chǎn)力，因?yàn)檫@個(gè)職業(yè)包含了這個(gè)社會(huì)太多人的技能，而不僅僅是代碼編寫、思維能力、行為模式等。從房東提出的問題可以預(yù)見，房東對(duì)這個(gè)職業(yè)了解不多。

那么我就從賺錢的角度（這可能是大多數(shù)人最關(guān)心的）告訴你前端和后端的利弊。

協(xié)調(diào)：北京（因?yàn)槲抑恢肋@一點(diǎn)，所以我也建議我年輕的時(shí)候，應(yīng)該在性價(jià)比更高的一線城市做程序員）。眾生——不是那么勤勞，也不是太有天賦：從入職到轉(zhuǎn)行，我基本上處于中等水平（或者可能是初級(jí)），程序員職業(yè)的工資在8-15k之間（不包括福利），在中等水平這個(gè)水平的學(xué)生，前面沒有什么區(qū)別而在后臺(tái)，他們中的大多數(shù)人都在寫業(yè)務(wù)或申請(qǐng)，他們中的大多數(shù)人都是為了運(yùn)氣而面試。如果他們是幸運(yùn)的，他們有一個(gè)低水平和高工資，但他們不是幸運(yùn)的，相反；

2。進(jìn)取型-非常勤奮，而且他們沒有太高的天賦：

這里我給出了“勤奮”的定義，即在整個(gè)程序員的職業(yè)生涯中不斷學(xué)習(xí)；

在這里每個(gè)間隔基本上都會(huì)達(dá)到準(zhǔn)高級(jí)的階段，而且很有可能成為高級(jí)。薪水大概在2.5-3萬之間，大多數(shù)能堅(jiān)持到這個(gè)階段的人都會(huì)有堅(jiān)持下去的理由，比如喜歡、愛、被生活所迫等等。在這種情況下，后端比前端更重要，因?yàn)楫?dāng)東西稀缺時(shí)，它總是很昂貴的。當(dāng)一個(gè)公司衡量一個(gè)人的工資時(shí)，它總是從稀缺性和不可替代性的角度來考慮支付多少。其他人的孩子-既有天賦又勤奮：

現(xiàn)階段的工資約為3-5萬，因此我們不能僅從以前的后端角度看待這一職業(yè)。基本上是滿堆的。這是基于默認(rèn)情況下，你沒有問題寫業(yè)務(wù)。在架構(gòu)方面，訪談主要集中在算法、優(yōu)化、兼容性、底層等方面。所以在這個(gè)階段，我們應(yīng)該有能力成為許多事情的專家；

4。剩下的部分-請(qǐng)?jiān)徫覜]有總結(jié)這種人，因?yàn)槲蚁氩怀鋈魏卧~來形容他們：

跳過它。。我對(duì)他們也不是很熟悉。它們基本上與我的代碼世界是平行的；

總而言之，如果我們簡單地混淆，我們可以看到哪一個(gè)容易開始，我們推薦前端。畢竟，閾值很低，單位時(shí)間早期的加速度很高。如果我們想有一個(gè)長遠(yuǎn)的計(jì)劃，在這個(gè)時(shí)代，我們必須精通多種能力。無論我們專攻前端還是后端，在一定程度上，我們都是神。

請(qǐng)問后端開發(fā)比前端開發(fā)工資高嗎？

同樣的經(jīng)驗(yàn)，后端相對(duì)要比前端高

但是應(yīng)該不會(huì)高很多

這并不意味著工資低，也就是說前端技術(shù)沒有后端技術(shù)難

前端的事情很瑣碎，說起來容易，說起來難

后端的事情應(yīng)該比前端復(fù)雜，要掌握的技術(shù)也比前端多，就像一些運(yùn)維技術(shù)，前端沒有，但是后端需要了解

后端開發(fā)通常也稱為服務(wù)器端開發(fā)，需要解決的問題要根據(jù)實(shí)際應(yīng)用場(chǎng)景來確定。技術(shù)選擇與服務(wù)規(guī)模直接相關(guān)。如果是大型服務(wù)，后端服務(wù)往往比較復(fù)雜，需要綜合考慮并發(fā)處理、事務(wù)處理、安全處理和資源分配等多個(gè)方面，通常采用分布式體系結(jié)構(gòu)來提高系統(tǒng)的處理能力和穩(wěn)定性。如果服務(wù)規(guī)模相對(duì)較小，后端服務(wù)的實(shí)現(xiàn)就容易得多。

大數(shù)據(jù)開發(fā)通常指大數(shù)據(jù)應(yīng)用開發(fā)。出發(fā)點(diǎn)是滿足系統(tǒng)的大數(shù)據(jù)處理任務(wù)，為后續(xù)的數(shù)據(jù)分析提供支持。當(dāng)然，大數(shù)據(jù)開發(fā)崗也包括大數(shù)據(jù)平臺(tái)的研發(fā)。與后端服務(wù)開發(fā)不同，大數(shù)據(jù)開發(fā)通常側(cè)重于數(shù)據(jù)操作，僅圍繞大數(shù)據(jù)平臺(tái)提供的API完成具體的數(shù)據(jù)操作任務(wù)。相對(duì)而言，大數(shù)據(jù)開發(fā)往往可以進(jìn)行功能封裝和重用，可以在一定程度上減輕開發(fā)負(fù)擔(dān)。另外，由于大部分?jǐn)?shù)據(jù)處理任務(wù)都可以通過平臺(tái)提供的功能來完成，大數(shù)據(jù)開發(fā)通常不需要考慮系統(tǒng)層面的問題，這也可以讓開發(fā)人員更加專注。

通常情況下，后端開發(fā)和大數(shù)據(jù)開發(fā)都有一定的壓力，但是哪個(gè)壓力更大，直接關(guān)系到業(yè)務(wù)類型和業(yè)務(wù)規(guī)模的發(fā)展。目前，我們正處在大數(shù)據(jù)時(shí)代。對(duì)于后端開發(fā)者來說，需要掌握大數(shù)據(jù)開發(fā)的相關(guān)知識(shí)，而對(duì)于后端開發(fā)者來說，學(xué)習(xí)大數(shù)據(jù)開發(fā)會(huì)比較順利。

最后，從行業(yè)發(fā)展趨勢(shì)來看，與大數(shù)據(jù)發(fā)展相關(guān)的工作在未來通常會(huì)有更多的發(fā)展機(jī)會(huì)，特別是在工業(yè)互聯(lián)網(wǎng)階段。

后端開發(fā)和大數(shù)據(jù)開發(fā)相比，哪個(gè)更累？哪個(gè)加班更多、壓力更大？

大型互聯(lián)網(wǎng)平臺(tái)的后端實(shí)現(xiàn)通常是一個(gè)復(fù)雜的過程。許多平臺(tái)將使用各種不同的編程語言，為用戶提供更快、更安全、更穩(wěn)定的體驗(yàn)。

從技術(shù)實(shí)現(xiàn)的角度來看，目前的互聯(lián)網(wǎng)平臺(tái)更多的是基于三大技術(shù)，一是分布式計(jì)算；二是分布式存儲(chǔ)；三是資源調(diào)度管理。這三項(xiàng)技術(shù)也是當(dāng)前大數(shù)據(jù)和云計(jì)算技術(shù)的基礎(chǔ)。

如果我們考慮技術(shù)解決方案的穩(wěn)定性和可擴(kuò)展性，更多的互聯(lián)網(wǎng)平臺(tái)將選擇使用java語言。一方面Java語言的性能比較穩(wěn)定，另一方面Java的生態(tài)系統(tǒng)比較健全，Java語言的成功案例很多，開發(fā)風(fēng)險(xiǎn)也會(huì)大大降低。與具體應(yīng)用層的實(shí)現(xiàn)相比，在構(gòu)建平臺(tái)（容器）的過程中，我們更注重性能和可擴(kuò)展性，而不是特別注重開發(fā)周期的長短和調(diào)整的方便性。因此，Java語言無疑是一個(gè)更合適的選擇。當(dāng)然，在構(gòu)建平臺(tái)的過程中，也會(huì)調(diào)用用C語言或C語言構(gòu)建的資源管理模塊。

除了Java之外，PHP和python也是常見的選擇。使用PHP進(jìn)行平臺(tái)開發(fā)往往具有較快的開發(fā)速度，但后期的擴(kuò)展，尤其是性能的提高，更多的依賴于云計(jì)算平臺(tái)的支持。然而，由于PHP具有自然熱部署的特性，PHP在后端開發(fā)領(lǐng)域得到了廣泛的應(yīng)用。另外，Python也是后端開發(fā)的通用編程語言。雖然Python和Java在性能上有一定的差距，但Python語言具有很強(qiáng)的資源管理能力和可擴(kuò)展性。

大型平臺(tái)的后臺(tái)都是用什么語言開發(fā)的？

一個(gè)非常好的問題。我是一個(gè)web應(yīng)用程序架構(gòu)師，多年來一直致力于回答這個(gè)問題。歡迎跟我來了解更多。

后端提供接口文檔為時(shí)已晚，這是合理和不合理的。根據(jù)具體情況，總有解決辦法。讓我談?wù)勎业挠^點(diǎn)。

不合理：成熟的技術(shù)團(tuán)隊(duì)重視功能設(shè)計(jì)，在編寫代碼之前有完整的技術(shù)文檔和功能定義。即使在TDD測(cè)試驅(qū)動(dòng)的開發(fā)模式下，測(cè)試數(shù)據(jù)已經(jīng)準(zhǔn)備好了，那么接口邏輯就已經(jīng)確定了接口文檔是否編寫好了，理清它們是很自然的。

-第一，主觀原因。原因是多方面的，比如趕進(jìn)度，沒有時(shí)間，不懶得寫，甚至在開發(fā)前沒有仔細(xì)設(shè)計(jì)，在做的時(shí)候也有變化。真的沒有好辦法。

-客觀原因：需求在變化，功能在變化，接口也在變化。所以，如果你寫了一個(gè)文件，它的自然更新和維護(hù)？天哪？

有解決方案嗎？建議嘗試：[1]swagger接口文檔，將文檔集成到代碼中，集成維護(hù)文檔和修改代碼，在修改代碼邏輯的同時(shí)方便修改文檔描述。

2、郵遞員界面測(cè)試工具，導(dǎo)入導(dǎo)出JSON文件，高效的團(tuán)隊(duì)合作。Postman支持各種請(qǐng)求方法和配置環(huán)境變量，對(duì)返回的結(jié)果進(jìn)行測(cè)試和驗(yàn)證，支持批量自動(dòng)操作，可與自動(dòng)構(gòu)建系統(tǒng)集成。

后端開發(fā)完接口才給出接口文檔，合理嗎？你怎么看？

一般來說，前者是為了用戶的可視化開發(fā)，而后者是為了前端所需要的一些數(shù)據(jù)，由業(yè)務(wù)處理來處理。

兩者相輔相成，但又不是缺一不可的

沒有前端，程序仍能運(yùn)行，但用戶看不到，卻能感覺到。例如，如果沒有back-e