為什麼一些企業還在使用SSH,不使用更新的框架原因是什麼?

時間 2021-05-08 17:54:15

1樓:猿來如此

1. 員工的學習成本,並不是每個員工都願意去學習別的技術。

2. 專案成本,既然專案能用,滿足現在需求,在正常執行了,何必再去重構折騰呢,可能重構完出現問題更麻煩。

2樓:閉麥i

先說我是個前端哈。其實你問這問題完全是屬於不成熟。如果當前架構足以支撐業務的話。

為啥要換框架呢?而且這其中還需要學習代價的好吧?並不是說新的東西一定好。

只能說適合自己的才是最好的。OK?

3樓:大黃鴨

老闆不關心技術,只關注功能和穩定性,開發經理可以公升級技術,但不能影響了現有的功能穩定性和客戶的使用,否則烏紗帽難保,誰敢輕易公升級

4樓:南城未雨

老專案用ssh,沒更新很正常,乙個系統的週期就那麼長,再更新框架費時費力費錢。

新專案還用ssh,可能有些模組和老專案是耦合的,或者某種原因必須得和原來的專案保持一致,這種就是沒辦法了。有些完全新的專案,和舊專案沒有一絲關聯的還用ssh,那公司的技術團隊肯定是有問題的,八成是公司很少補充新的技術人才,舊的員工又懶得學習新東西,沒有人牽頭搞。這樣的公司沒必要久待,很可能公司發展不夠好,發展可以的公司通常每年都會擴招員工。

5樓:Marcos

一方面,公司的開發人員沒有更新自己的技術能力,另外一方面,很多業務使用SSH也能很好的支撐業務,更新技術並不能帶來更高的效率

6樓:大頭菜

因為框架講究的不是最新最優秀,而是要聚焦是否滿足需求。滿足需求的前提下,需要聚焦是否成熟。成熟代表bug少。

還有需要考慮運維,是否熟悉springboot,如果不熟悉,上線後出故障。誰來維護。怕的不是出bug,怕的是出bug後,沒人修。

7樓:

新框架如果要用,大部分也肯定在新專案長會上。

老專案沒公升級的動力,畢竟跑的好好的,沒問題誰會去折騰?老闆也不會給你資源和時間,萬一改出個問題(根據我的上線定律,凡事上線一定會出事),你作為第一負責人要擔責的,所以除非新的需求不能在老專案裡改,否則改框架這種事正常是絕對不會有的。

有個問題是很多公司為首不公升級 jdk,我很多服務都還在 jdk 6上跑,幾年都不會去管它,跑得好好的,幹嘛去公升級?公升級了萬一有點不相容那不是要我的錢?

當然現在開微服務以後就好多了,新開微服務肯定盡量上新技術,也學習一下。

8樓:

首先,會用SSH,上手Spring boot頂多就一周時間吧,真談不上什麼團隊學習成本的問題。再者,Spring boot並非什麼新玩意,你用Spring boot,難道就不用SSH、SSM了麼?它的流行無非兩點:

1. 約定優於配置,自動配置,極大地簡化了Spring應用程式的開發過程,提高了開發效率。2.

微服務架構的流行。

既然如此,為嘛公司不採用Spring boot?背後的原因是什麼?前面已經有人回答了幾點,比如:

夠用;約定優於配置並非萬能的。還有兩個可能的原因是:1.

Spring boot要求JDK 8,如果已有其他系統的生產伺服器上JDK是更低版本呢?2.有些公司已經有對SSH/SSM二次封裝的框架,已經經歷了很多專案,團隊開發效率本來就大幅度提高了,不需要再用Spring boot折騰一遍。

9樓:Alexander Huang

1、現有業務要保障穩定以及提高投入產出比。老的業務框架在滿足既定效能前提下,能不動就不動,動就意味著不穩定,有風險;另外一方面,新框架需要學習成本的,這樣投入產出比不理想,團隊負責人有政績要求,一般不會貿然做費力不討好的事情

2、新業務遇到的問題是受限老框架或者老業務影響,新老框架不相容,沒辦法用新框架。直接造輪子的話,技術委員會評審一般也過不了的。

總的來說,企業是要活下去、可持續發展的,需要平衡成本、成果、效率的,為了新框架而新框架本身就是對企業本身的不負責任。新框架的使用往往是在現有架構不能支撐業務時應運而生的。還是要看企業的自身發展狀態

10樓:小白

一般這樣說的都是新員工吧.那新技術出了問題誰來解決,老員工可以以沒接觸過不幫忙處理,新員工又扛不住,基本GG.

而且對於領導來說夠用就可以了幹嘛要換新技術,時間成本,試錯成本怎麼辦?

11樓:Karl008

SSH是傳統的一套開發框架,適合一些小公司業務不是很複雜。可以節約開發成本。

使用新框架帶來的就是技術改革需要投入很多的人力物力。

看企業的選擇了。

12樓:2gua

業務支撐得起來,對於老闆來講,賺錢是第一要務,何必折騰呢?萬一折騰出問題了不是沒事找事嗎?——不能光從技術人員怎麼爽角度看待問題。

公司的技術儲備支撐得其新的嘗試嗎?技術團隊對新嘗試的意願強烈與否?——從團隊技術角度考慮問題。

個人想學習新的技術棧?如果公司不能滿足個人需求,那就考慮一下換個環境——個人發展角度考慮問題。

13樓:

老專案吧,ssh能跑就行,新專案可能就會用ssm(spring boot, spring mvc, mybatis/mybatis plus)。

14樓:乙隻程式設計師

我比較好奇的是如果乙個老專案一直執行正常,也沒啥效能問題(企業應用沒多少併發),為啥要換新框架呢?

如果乙個新專案沒使用新框架,多半是沒人牽頭,其實小公司沒有牽頭人,更多的是你用你的,我用我的,反正是模組化,最後能粘起來用就行。

15樓:IT老魁

1,企業用的很成熟了,不會隨意去更換乙個架構,畢竟乙個新的架構要想穩定,需要時間成本

2,企業it團隊對該技術的人員儲備比較好,也比較熟悉,不願意重新全員的學習新架構

3,本生要建的系統用ssm等就已經足夠了,也不需要什麼高併發微服務技術

4,springboot對於某些系統並不適用,相反,老的ssm等反而更好

5,如果不是雲原生的架構,實際用springboot可能還不如ssm效率高,運維成本也是考慮的範圍

說了這麼多,其實就是懶得換,不想折騰。。。。。

16樓:jac0625

有些公司的團隊,雖然舊技術已經過時,但是他已經形成自己的一套適合自己的開發周期很短的一套模板,團隊使用起來比較順手.再就是可能更新團隊的技術需要的代價比較大,比如說人員成本,新技術學習的成本等等.

17樓:hzldds2020

都是歷史原因了。

舊的專案需要維護。

springboot也有它的侷限性,別以為annotation一定就很香,大型專案配置還是寫得明明白白好一些。如果是線上生產系統,面臨臨時性問題處理,改動xml配置即可,annotation還要打包編譯上線,中間還有各級領導審批,等這些個搞完了COE的事故定級都上公升了,喝西北風去?

18樓:會喝水的杯子

我現在維護的乙個專案,ssh。

兩個原因,主導的人就會ssh,上線deadline太短。

當時的開發團隊就我和另乙個同事springboot那一套東西。

新來的跟我一起維護同事我為啥還用這麼舊的技術,我只能說當時開發周期太短。

為什麼一些linux自帶python,而不是C,C ,java等其他程式語言?

charlary 第一句話對,第二句話就錯了,幾乎所有的linux發行版都有c和c 沒有libc的linux和裸核心基本沒什麼區別 大多數發行版都有jvm 沒有jvm,好像gnome都無法啟動 原因是系統自帶軟體裡有些是依賴 python 的,其實也自帶了 C C runtime 和一些已編譯好的庫...

為什麼很多企業願意花錢去使用企業郵箱而不是自己搭建電子郵件伺服器?

sjhfjga 自建郵箱耗費大量人力物力財力,而且自建郵箱很難達到各大企業郵箱公司那樣好用,經常碰到各種問題。外包給企郵服務商的話 比如263 省去麻煩,也節省大量資源,出現問題時可以隨時諮詢專業人員。並且安全姓很高。 鄧戀 1 成本更低 特別是運維的成本 2 更穩定 外包的郵箱至少是已經看到的在市...

英雄聯盟為什麼不增強一些弱勢英雄

大蘿蔔 卡特玩家來答一發,拿卡特來說。從改版到現在,絕大多數時間卡特都在不溫不火的狀態,如果你不是專玩這個的,你一定不會拿著英雄出來玩,因為他太吃熟練度了。同理,如果是專精卡特的玩家,稍微有所加強,就會大殺四方。這種英雄,加強就會強的離譜,所以說你看起來很強的英雄,他是可以加強的,但是有的英雄不行 ...