【原創】大公司爲何還在採用過期的技術

背景

本文出自一朋友給個人提問,因而博主嘔心瀝血給他花式洗腦了幾個小時。突然發現,應該還有許多朋友有一樣的疑問。因此整理成文。
許多剛畢業的程序員朋友,都有一個執念,想要進那種規模大一點的公司、上市的、業內有名的最好。
爲何你們都想去大公司?
由於不少人以爲,公司大一點,正規一點。開發技術應該不錯,應該與時俱進,流程應該會規範一些。說到這裏,依然有這種想法的朋友,請握個爪。
然而,當他刷完什麼《劍指OFFER》《編程之美》,廢了好大一番功夫進去之後,卻發現徹底和本身想的不同。他發現他所在的大公司:程序員

(1)代碼混亂

I、好比一個發送Http請求的Util類,居然出現了三四種。開發人員A封裝了一種,開發人員B封裝了一種,公司框架自帶了一種。
II、處處充斥着Ctrl+CCtrl+V的味道,更有甚者,竟然連author都不改,原樣複製過去。
III、日誌風格千奇百怪,缺少統一規範。每一個人都有一套本身的日誌風格。重點是,一些關鍵步驟,竟然不寫日誌。
IV、一些幾千行的類、關鍵步驟不加註釋、一個方法幾十個參數都是隨處可見。編程

(2)開發流程混亂

I、一個項目組IDEJDK都不統一,好比用Idea,eclipse,myeclipse的都有。然而重點是,把idea、eclipse獨有的配置文件都上傳到了服務器。
II、徹底沒有文檔。好比要改一個需求了,OK,去Debug代碼,根據斷點去反推原來的邏輯是怎麼實現的。反正不改出問題就行。
III、程序員白天大部分時間在處理BUG,以一種混日子的態度在工做。反正能搞得定新需求,搞得定功能測試,項目能如期上線就行。至於代碼有多搓,無所謂!服務器

(3)技術落後

I、還在用四五年前的技術,例如還在JSP裏頭寫大量的JAVA代碼進行開發等。
II、架構上不少方面欠考慮。好比,採用了消息隊列,卻徹底不作持久化處理,徹底不擔憂數據丟失的問題,也沒作可靠性的保證。服務之間傳送數據,重要信息徹底不加密,明文直接傳。
III、性能調優就是拍腦殼作的架構

以上種種,你們若是深有感觸,請再次握個爪。那麼,爲何會這樣呢?框架

原因

人員層次

但凡在大廠工做幾年的老員工,有沒有這樣一個體會,身邊的牛逼老員工基本都跑了,剩下來的員工基本都是比較平庸的。
大部分人在工做中,其實都處在一種重複勞動的狀態,也就是所謂的擰螺絲工做,技術水平得不到提升。那麼在這種工做性質之下,會誕生兩類人:
(1)平庸的人
這類人在工做中知足於能完成需求便可,對代碼的美醜並不關心。正所謂eclipse

碼不在爛,能跑就行。ide

固然,這類人並非缺少提高本身技術的能力,而是因爲惰性,沒有明確的規劃,缺少提高技能的意識,致使時光匆匆流走,想要跳槽卻沒地方收留,一不當心,這類人就成爲了老員工。說到這裏,趕忙回憶一下本身,是否是整天拿什麼沒時間當理由,而後明日復明日,當心成爲老員工。
另外,大公司基本不會裁員,而手上的技術水平已經能應付工做。就算努力學了一堆新技術,也沒有用武之地,因而這類人就能安然自得的繼續過下去。
你們能夠對比一下你身邊的同事,一個是自畢業的時候就在這家公司熬了十年的,一個是十年間在三四家公司呆過的。請問哪個水平更高呢?
(2)牛逼的人
這類人在工做中,通常有着較強的責任心,且對代碼有着很高的追求,對問題有着獨特的看法,回去也會不斷的學習,提高本身。然而這類人的所學,一般沒有發揮的空間。好比,可能出現下面的對話性能

程序員A:"老王,你這個地方不能這麼寫,會出現XXX的BUG的。"
老王:"你懂什麼,公司創立的時候,我就在這個項目組了,就該這麼寫。"
學習

因而這類人的所學,並無啥發揮空間。就算有發揮的空間,過不了多久,他也會離職。由於在IT圈,只有經過跳槽才能獲得高薪。這點,咱們必須明白,大廠都有一套嚴格的薪水漲幅制度,並不會由於你作出了特別牛逼的貢獻,給你月薪忽然翻了一倍。並且,若是給你漲了薪水,你公司的其餘人呢,他們漲仍是不漲?因此,不少公司寧願給一個新員工高薪,卻不肯意給老員工提工資,就是這個道理。
所以,這類牛逼的人以爲公司現有的薪資匹配不上本身的能力後,就會跑路的。你們在IT圈會聽到一個說法測試

B級公司就是給A級公司培養人才的,A級公司就是給S級公司培養人才的。

因此,當你發現本身身邊沒有牛逼的大神,不要驚訝,由於大神都跑路了。

重構成本

當一個系統的代碼,成爲祖傳代碼之後,其業務規模和複雜程度,都遠遠超乎你的想象。咱們在開發新需求的時候,都是在原有基礎上當心翼翼的修補。好比,可能出現以下對話

老王:"誰讓你亂改這個模塊代碼的,知不知道,你這麼改致使了XX模塊不能用了。"
程序員A:「我。。。。只是想讓代碼看起來更好看而已。」
老王:"你覺得我不知道這麼寫很挫麼,亂改出問題了,你抗麼。趕忙改回去。"

其實你能看到的問題,老員工看的比你更清楚,maybe人家比你還明白應該要如何解決。可是爲何老員工不去作呢?由於,老員工明白,技術上的事情沒有100%確定不出事的。出了事了,誰來背?

再打一個比方,

你一個月薪水10K,你花了5個月的時間,提高了一下10%性能。站在你的角度,你高興了。可是站在公司的角度,臥槽,我虧了啊。我還不如花20K再買一臺機器。在你身上投入了50K,還要擔憂你會不會跑路。

因此,從重構成本上來看,又提升了。
另外,不少中層的領導,基本都是守着本身的一畝三分地,不求無功,但求無過。所謂祖傳代碼的出現,實際上是整個部門的責任。你一我的重構的開開心心了,後續就可能整個部門一塊兒加班,誰去作這種吃力不討好的事情。並且最重要的是,在技術leader水平和開發流程沒有改變的狀況下,你的新代碼過不了幾個月又會變成所謂的祖傳代碼。

固然,可是這並不意味着,這些技術項目沒救了。好比,某一天你的對手,出了個吊打大家項目的產品。這種時候,只能大改了。反正搏一搏,沒準還有出路呢。

公司性質

其實,大部分的公司都是重視業務價值,而看不到技術價值
有些大廠存在一個頗有趣的現象,產品經理的薪資比技術人員的薪資還高。由於他們以爲,無外乎是增刪改嘛,找點應屆生就能做了,不必花大價錢請牛逼的人來寫。
因而呢,不少中層是所謂的沒寫過代碼的業務員,又或者是沒擼過一行的代碼的產品經理,而後就很搞笑了,會出現以下情形

產品經理:"這個功能,大家看一下要多久才能實現。"
研發人員:"大概下個月十五左右吧。"
產品經理:"什麼!要這麼久。就初一,下個月初一,必定要上。"
研發人員:"我!!!!這個功能XX地方比較複雜,須要點時間。"
產品經理:"你當我傻麼,就是if else。。能夠實現的,怎麼要這麼久!"
研發人員:"我!!!"
產品經理:"就下個月初一了,作不出來,公司的損失你背仍是我背!"

因而呢,在重視業務價值的公司,不管你多牛逼,乃至你是碼神下凡,你寫出的代碼也是不堪入目。說到這裏,博主的那個朋友不服,他辯解道

"咱們能夠在前期作好設計和規劃後,再開始開發啊,這樣就能減小出現渣渣代碼的可能性。"

確實,我認可這麼作能夠減小出現爛代碼的可能性。然而,你們都知道,需求是一個善變的小姑娘,一天一個樣。你再牛逼的設計,也頂不住需求的頻繁變動啊。
其實,在某些時候,沒有必要把代碼當成一種藝術品,應該要可以接受適當程度的瑕疵。只要到點能夠跑,能夠追蹤BUG,基本能交差就成。我相信,給任何一我的足夠的時間,都能把代碼變成一個藝術品,可是這有什麼用。等你弄好,黃花菜都涼了。迅速上線,能掙到錢纔是重點啊,纔是你的KPI體現啊。不少優秀的代碼,是給了重構的時間的,大牛們都是一邊寫一邊重構的。若是不給時間,大牛們也寫不出優秀的代碼的。換句話說,你徹底能夠後面掙到錢之後,再把原來的架構推導重來。
咱們要明白,寫代碼是爲了掙錢,而不是爲了雕琢一個所謂的藝術品。若是將寫優秀代碼比做一種情懷,請問

情懷重要,仍是金錢重要?情懷能讓你買房麼。

OK,弄清楚主次,掙錢纔是硬道理。

審視本身

這個地方,我但願你們好好審視一下本身,由於重點不是

大公司爲何還在採用過期的技術

而是

你爲何只能進採用過期技術的公司

其實,每個公司都有一個所謂的標杆部門,這個部門的技術一般是拿的出手的。但是,這樣的部門,一般是最難進的。因此啊,你要去拿的出手的部門,好好努力吧,少年們。
OK,到這裏,你們好好思考一下吧。你們有什麼問題,也能夠給我留言。

總結

囉裏囉唆的扯了一堆,但願你們看完之後,能有所收穫。工做中,不斷的提高本身,少一些抱怨吧。

相關文章
相關標籤/搜索