Laravel 和 Spring Boot 兩個框架比較創業篇(二:人工成本)

曾俊傑發表於2019-03-10

前面從開發效率比較了 Laravel 和 Spring Boot兩個框架,見:Laravel 和 Spring Boot 兩個框架比較創業篇(一:開發效率) ,這一篇打算比較一下人工成本。

本文說的人工成本是狹義的技術支出成本。當然人工成本不單純是開發人員的人工成本,同時包含了團隊協作管理、架構設計、運維等方面的人工(團隊)成本。

本文從以下幾個維度分析:

  • 程式設計師
  • 技術管理

程式設計師

相信這個是大家比較關注的維度,很好理解,就是要根據需求擼一套產品出來,無論是後端、前端、APP還是小程式、中臺,都要士兵衝鋒前陣,也就是靠程式設計師實現出來,所以這個是剛需。

相信很多猿都會認為自己是全棧工程師,後端OK、前端也OK、APP也能擼,微信小程式也沒問題,這樣的人還是不少的,但是大部分是停留在框架或者類庫的使用上,稱為 “github工程師”,必然會有自己比較精的一個端。

例如前端的Single Page Application,一般現代的猿對JavaScript語言都會了解,如果對Vue技術熟悉,配合Vue Route、Element UI、Vuex 就能擼出一個像模像樣的SPA,如果對 React 語法和單向資料流思維熟悉,Dvajs + Ant Design也能擼出一個絢麗的中臺系統。

對於Android開發,熟悉 Java 語法,瞭解 Android 四大元件,不需要對Android Framework 核心、NDK 有深入的理解,只要有大牛工具庫的加持,例如Retrofit、EventBus、GreenDao、,也能擼出一個看起來還不錯原生Android APP。何況還有Flutter!

現代框架的高度封裝特性使生產力獲得提高,同時容易讓開發人員對底層原理失去探索需求,這種失去不但體現在開發人員本身,同樣也體現在軟體企業在人才篩選上為了降低成本而對技術要求做出讓步。

大廠考底層原理和演算法、初創看專案經驗,這似乎成為了一種行業規律。

不扯遠了,回到找猿的話題。

Spring Boot 猿

  • Java 猿多,優秀的 Java 猿難找,有專案思路快速出專案的Java程式猿太難找
  • J2EE 猿多,優秀的 J2EE 猿太難找,熟悉 J2EE 體系、精通 Spring 全家桶的猿更是難找
  • 精通 J2EE 而且能適應 Spring Boot 開發思維的猿可遇不可求

J2EE 非常龐大複雜,知識點數量不亞於一本字典,Spring Boot 配置方式從傳統的xml定義向Java類注入轉變,現在很多J2EE 猿仍然是起手一個裹腳布似的xml配置檔案,一看洋洋灑灑上千行,看起來牛逼,其實只是剛把專案執行起來而已,九九八十一關才過了一關。也正是因為傳統J2EE的這個特點,Java 給人一種開發速度慢、成本高的印象。

Java Web 體系就像飲食業

J2EE飯店內,只見顧客光著膀子走進飯店,和工作人員說道:我要紅色的襯衣,釦子要六角形的,鞋子要皮鞋黑色的,吃飯的筷子要長度16cm,木頭做的,吃飯的椅子要四隻腳的,墊子厚度1cm,6號桌子...,一個小時後一切定製完畢,可以吃飯了。

Spring Boot飯店內人不多,迎賓在聲嘶力竭的呼喊:“南來得北往的老少爺們,快來看看瞧瞧啦”,一個顧客走過來,迎賓馬上把他迎進大廳領到空桌坐下,服務員拿出選單,問道:“您要吃點什麼呢?”。顧客露出驚訝的表情:“我還沒有定製我的衣服、筷子、椅子呢?”。服務員道:“我們都準備好了,每個顧客都一樣,16cm的筷子,四隻腳的椅子,1cm墊子,不需要定製呢,您可以直接點菜用餐”。顧客停了一會說道:“墊子我要1.5cm的,其他的就這樣吧”,服務員:“好嘞”。顧客點了一個驢肉火燒,15分鐘後吃飽了滿足的離開了店裡,喃喃說著:“以後再也不去J2EE飯店了,還是這裡方便。”

因此我們要找的不是Java猿,也不是J2EE猿,而是Spring Boot猿。

價格方面

  • 6k可以招到Java猿,但是不能指望他能獨當一面,獨立負責你的專案開發,而且要花費精力和資源去培訓
  • 10K能招到一個會 Spring Boot的猿,J2EE熟不熟悉就不知道了,你猜
  • 15k能招到一個靠譜的J2EE猿
  • 20K運氣好的話能夠招到一個懂 J2EE 而且能用Spring Boot框架獨立開發後端的靠譜猿

貌似成本不低。

Laravel

  • PHP猿很多,等等,先讓我們過濾一下,啥?會Discuz、DeDeCms、帝國Cms?用原生PHP開發一個專案會嗎?不會?那算了
  • 遵守規範、程式碼漂亮的PHP猿少,PSR是啥?我也不知道?呃...
  • 自制力強的猿少,咦,這個功能加個全域性function就搞定了,就這麼幹。這麼簡單的業務邏輯也就100多行,我邏輯思維能力超強,直接寫在controller方法裡吧,看我開發速度多快。團隊成員:呃...
  • PHP猿懟道:我會ThinkPHP,你說 Laravel 搞得和Java一樣複雜,你幹嘛不去找Java猿,國內 Laravel 人才還真不多

價格方面

  • 3k可以招到“CMS PHP猿”
  • 6k可以招到PHP猿,同樣不能指望他能獨當一面,獨立負責你的專案開發,而且要花費精力和資源去培訓
  • 15K也是能夠招到一個靠譜Laravel 猿,當然這裡面的運氣成分很大,嗯,天時地利人和,缺一不可。

技術管理

啥?技術管理是啥?CTO嗎?小專案還折騰啥CTO?

其實不然,當開始一個專案的時候,產出的軟體不可能只是一個端,至少需要後端和前端,或者APP端、小程式端。

技術管理的作用是協調各個端的互動和介面規範,還有專案開發里程碑和任務安排 (注意不包含架構,在初創快速實現的強烈需求下,架構先不考慮)。我們不可能讓專職後端來制定APP端的里程碑,同樣也不能夠讓專職APP客戶端來定後端的里程碑。必然會有一個技術比較全面的樞紐人物,我認為這是專案快速推進的基礎,同樣也可以負責測試和code review。儘管這和產品經理有點類似,對於產品規劃較全面的初創來說,是可以合二為一的。出於成本考慮,我們需要低成本招到這樣的人來統攬專案技術全域性。

後端在產品體系中屬於重合度最高的端,需要和每個端產生互動,最低成本的方式是將技術管理這部分成本附加到後端,說人話:“找一個符合前面所述開發要求的全棧後端來承擔技術管理工作”。

個人總結(按照通用水平,大神級別的不在討論範圍內):

  • 對於專職後端:Laravel 人工成本要略低於 Spring Boot
  • 對於技術管理:指令碼系(PHP、Python、JavaScript)的猿往往更容易向全棧發展,J2EE 這種企業級巨無霸框架,分工概念很強,比起指令碼系語言全棧工程師就顯得更少。而且既能勝任J2EE+Spring Boot 開發,又是全棧的猿,初創還是不要考慮了,太貴。
  • 從PHP猿中找到符合初創技術管理要求的,概率要比從Java猿裡面找高一些,參考物件多,議價能力自然也高些。
  • 在不考慮系統架構優劣的前提下,人工成本方面 Laravel 比 Spring Boot 更有優勢

最後再多嘴說一句初創的軟體系統架構問題:我接觸過很多初創,而且還把軟體系統架構看的很重,這是一個嚴重的誤區。正如網友們說的,Laravel 存在效能問題,為了做大之後流量大了服務不掛掉,嚷嚷著要上微服務。

產品上線了沒?產品都還沒上線,要啥高併發,要啥高效能,要啥微服務。

初創專案一般流量不大,也不是計算密集型服務,效能瓶頸不會是在PHP框架本身,沒有必要糾結是 C/C++JVM誰執行速度快,PHPC慢了多少個數量級,這些毫無意義。當你有了這個效能需求的時候,如果公司還沒那個資金去高薪找人才,那商業模式真的是沒誰了!

還有微服務,一個街邊小攤嚷嚷著要按照阿里巴巴的運營模式來搞,其實這樣沒啥問題,自己選的路,冷暖自知吧。微服務天生就是分散式,分散式本身就是一個非常大的系統,不是初創適合玩的。就像跨國運營戰略適合阿里這種體量的公司,因為業務複雜度已經到達了某種程度,經過評估是對公司短、中、長期發展都是有利的。街邊小攤套用這種模式,只會被複雜度困住手腳,當然當您的小吃邁出國門,走向世界,手底下幾千人,戰略模式自然就有了。當軟體複雜度和專案業務量到達一定程度,有了服務拆分和分散式需求,微服務自然就有了,初創要做的可能是關注擴充套件性,並不是微服務。

Laravel 和 Spring Boot 兩個框架比較創業篇(二:人工成本)

小流量前提下談高併發和架構就是耍流氓!您要的可能不是架構,而是擴充套件性!

相關文章