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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-客觀原因：需求在變化，功能在變化，接口也在變化。所以，如果你寫(xiě)了一個(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)集成。

后端提供給前端的接口是什么樣的？

一般來(lái)說(shuō)，沒(méi)有前端到后端的接口。它們幾乎都是后端到前端的接口。所謂接口就是通過(guò)服務(wù)器部署的機(jī)器提供的URL地址進(jìn)行動(dòng)態(tài)數(shù)據(jù)交互。通常，后端和前端協(xié)商定義數(shù)據(jù)接口格式（一般是JSON格式）形成一個(gè)文檔，后端實(shí)現(xiàn)接口，前端做靜態(tài)模擬（可以直接在頁(yè)面的JS中拼假數(shù)據(jù)，也可以通過(guò)jsonserver按照真實(shí)的方式調(diào)用服務(wù)），后端實(shí)現(xiàn)服務(wù)接口，雙方完成集成和聯(lián)調(diào)?，F(xiàn)在有了swagger或者apiairy這樣的工具可以簡(jiǎn)化這個(gè)過(guò)程

要找出這個(gè)問(wèn)題，首先我們需要找出前端和后端的開(kāi)發(fā)職責(zé)。

那么前端和后端是如何交互的呢？在大多數(shù)情況下，雙方通過(guò)接口進(jìn)行交互。前端通過(guò)接口將請(qǐng)求發(fā)送到后臺(tái)，后臺(tái)接收請(qǐng)求進(jìn)行業(yè)務(wù)處理，并將處理結(jié)果反饋給前端。當(dāng)然，也可以說(shuō)一方觸發(fā)一個(gè)事件，然后事件的描述通過(guò)特定的協(xié)議與前后站進(jìn)行通信。一般來(lái)說(shuō)，雙方都約定了一定的命令、約定、攜帶信息的格式和說(shuō)明，以及約定方式對(duì)某項(xiàng)業(yè)務(wù)返回結(jié)果的說(shuō)明。通常，API文檔是在后臺(tái)提供的。文件受版本控制。如有變更，應(yīng)及時(shí)通知前臺(tái)開(kāi)發(fā)人員，同時(shí)將變更說(shuō)明寫(xiě)清楚。前臺(tái)根據(jù)文檔使用一些模擬框架來(lái)模擬數(shù)據(jù)開(kāi)發(fā)。這是現(xiàn)在流行的，也稱為前后分離。開(kāi)發(fā)完成后，前臺(tái)將連接后臺(tái)測(cè)試應(yīng)用進(jìn)行測(cè)試。測(cè)試人員會(huì)通過(guò)一些協(xié)作平臺(tái)（如JIRA、tower等）將測(cè)試出的bug反饋給開(kāi)發(fā)人員，并在開(kāi)發(fā)人員修復(fù)后進(jìn)行測(cè)試。一直到要求的結(jié)果。隨后的新需求以上述方式重復(fù)，也稱為軟件迭代。

這就完成了軟件迭代的整個(gè)過(guò)程。軟件工程是一個(gè)系統(tǒng)工程。需要來(lái)自不同位置的人一起寫(xiě)作。希望我的答案對(duì)你有用

搜培，這是最常用的接口測(cè)試工具。

在我們的日常開(kāi)發(fā)過(guò)程中，大多數(shù)是兩種類型的接口：soap API和rest API。Soupui對(duì)這兩個(gè)接口都有很好的支持，而且它還支持Amazon Web服務(wù)，它只出現(xiàn)在軟件的首頁(yè)上，但沒(méi)有實(shí)際使用。

事實(shí)上，許多接口測(cè)試工具都很好地支持這兩種常見(jiàn)接口。這里我不詳細(xì)說(shuō)明具體用法。它們都是圖形界面操作。您可以根據(jù)說(shuō)明一步一步地創(chuàng)建一個(gè)新接口。

其中，壓力測(cè)試非常方便，也可以根據(jù)提示逐步創(chuàng)建。最后的操作頁(yè)面是這樣的：

您可以設(shè)置：并發(fā)數(shù)、策略、壓力測(cè)試時(shí)間等

結(jié)果可以顯示：最大響應(yīng)時(shí)間、最小響應(yīng)時(shí)間、平均響應(yīng)時(shí)間、TPS等。

非常容易使用，您可以嘗試。

軟件開(kāi)發(fā)中前端和后端如何協(xié)同開(kāi)發(fā)和集成？

目前，為了提高開(kāi)發(fā)效率，很多公司采用了前端和后端分離的開(kāi)發(fā)模式，即架構(gòu)的分離和解耦。前端和后端執(zhí)行各自的任務(wù)，并通過(guò)restfulapi調(diào)用數(shù)據(jù)。這種方式有很多優(yōu)點(diǎn)，比如：前后端分離部署：降低了后端服務(wù)器的壓力，后端服務(wù)器不需要負(fù)責(zé)前端頁(yè)面的呈現(xiàn)，只負(fù)責(zé)數(shù)據(jù)的處理，所以性能會(huì)得到提高；

高重用性：前后端分離本質(zhì)上也是系統(tǒng)分離，它可以實(shí)現(xiàn)同一個(gè)后端系統(tǒng)向多個(gè)前端系統(tǒng)提供數(shù)據(jù)，并且具有良好的可擴(kuò)展性更高；

并行開(kāi)發(fā)，提高效率：前端和后端并行開(kāi)發(fā)，提前約定好數(shù)據(jù)格式（mock），提高項(xiàng)目開(kāi)發(fā)效率。

但是，前端和后端的分離也帶來(lái)了一些問(wèn)題，例如第一次屏幕加載和渲染時(shí)間。

至于前端和后端的分離是否會(huì)影響第一次屏幕加載，我想說(shuō)的是有很多，但影響的程度取決于代碼的質(zhì)量。只要優(yōu)化效果好，第一屏加載時(shí)間不會(huì)太慢。

，與大家分享：

前端和后端分開(kāi)部署，CDN加速；

前端盡量少調(diào)用多個(gè)API，建議調(diào)用一個(gè)API網(wǎng)關(guān)來(lái)實(shí)現(xiàn)