[[269371]]

 一、寫作背景

二、各類型公司的環境氛圍

三、各類型公司的開發流程規范

四、如何提高在公司的核心競爭力

五、一些中肯建議

一、寫作背景

本人在大學期間有過三段實習，大二在一家外包公司，大三去了技術型公司，現在待在一個業務驅動型公司。認識我比較久的讀者應該知道，我經歷了一次優秀實習生，兩次提前轉正，最近這份工作原本半年的試用實習期，只實習了一個月就提前轉正。

寫這篇文章有三個目的：

1. 純粹地分享這三家的工作經歷。

2. 分享的同時，給在校生和未在這些公司中從事工作的同學一些參考。畢竟在自己沒有真正經歷過之前，都只是別人口中所說，也是所謂的「圍城」。

3.由于本人有階段性復盤的習慣，對這三段工作的表現自認為還可以，這邊也會針對不同類型的公司分享一些提高核心競爭力的經驗。

二、各類型公司的環境氛圍

①外包

我們當時團隊有10個人，入駐到一家國企里面進行開發，分配給我們的只有一個小房間，而且這個房間之前還是倉庫，在公司的最角落。

房間里面的氛圍「很符合」開發氣氛，只有到飯點了有人喊吃飯了才有聲音，其他時候一片寂靜。

這家國企有自己的食堂，他們的員工都是包餐的，人手一張卡。但是這家企業給到我們團隊的只有一張卡，也就是我們團隊共用一張卡，所以到食堂之后我們得排在一起輪流刷。吃完飯之后，團隊的每個人需要給CTO轉12元作為中午的飯錢，CTO收完之后統一轉給該企業財務，也就是我們不包餐。

輪流刷卡，不包餐這些都還好，畢竟外包團隊嘛，也能理解。但是食堂有時在節假日特意煮了湯或者其他什么的，一看到我們團隊來了，就直接說我們沒有。有一次中秋節，人事部在食堂門口發禮盒，團隊的老員工要去領，人事部的人由于對我們比較陌生，于是問了一下基本信息，一聽到我們是技術部的，趕緊揮了揮手說沒有。

雖然這家外包996，一個月只發我800工資，而且還用支付寶轉賬，但我還是挺感激給予我這樣的機會讓我學習，沒有「歸屬感」和「認同感」也告訴我僅僅只能實習，這兩種感覺相信在外包的朋友都深有體會。

②技術導向型

這家公司是真正意義上的技術型公司，公司產品的核心競爭力就是技術，解決市場上其他競品解決不了的。

該公司的創始人及管理層全都是技術人員出身，企業內部還設了一個大學，上面有必修課和選修課，上完課之后要參加考試，考試成績作為年終績效指標之一。上到HR，下到底層研發人員都得接受大數據知識的洗禮，隨口就是各種Hadoop、Spark。除此之外，公司還會經常外界技術人士來公司分享，企業內部也會經常性做分享。

這種技術氛圍也是每個技術人所向往的，遇到什么難題，內部員工頭腦風暴一下就能解決。

這種企業里的技術人員是具備核心地位的，核心部門也必須是開發部，并且針對不同的技術，內部分工會分的比較細，具體到哪個模塊，哪個功能。

③業務驅動型

在這種公司，開發部門正常都不是核心部門，但同時又是不可缺少的。拿我現在的電商公司來說，數據部門主要是為了給運營部提供一些數據讓他們更好地去定價，定制活動等。

公司的核心競爭力應該是產品，其次是模式，而模式包含著運營、銷售等。技術只是作為輔助這種模式建立的一份子，搭建一個平臺，或者出一些指標數據，都是為了更好服務業務。

市面上大部分互聯網公司都是業務驅動型公司，這類公司會把部分邊緣業務外包出去，重點做核心業務，對于核心業務的技術又沒像技術型公司一樣苛刻，謀求最佳性價比。

三、各類型公司的開發流程規范

①外包

「不管是爛代碼還是冗余代碼，只要能實現功能的就是好代碼」。大部分的外包公司或者說基本所有的外包公司都不會做code review，只要能把功能實現交給客戶就行。

大二的時候，我們團隊雖然駐扎在一家國企里面，但真正做該企業項目的只有我一個人，其他人都在做不同的項目。我那時既自豪又感概，自豪地跟同學說我自己一個人搞一個國企項目，感慨公司心真大，把一個國企項目交給我的一個實習生來做。

那時也不懂什么叫好代碼，都是沖著功能實現去的，各種調包，copy & paster，if else while for常常寫出「死亡三角」，沒人批評我說代碼寫的丑，沒人讓我封裝，都是夸我功能實現的快，就是bug多了點。

產品經理時不時地走到我身邊，跟我說要加哪些功能，哪些不要，業務邏輯都是freestyle，現場畫邏輯圖。剛開始不懂，認真地聽產品經理說，然后拿小本本記。后來我的leader跟我說：「別聽產品經理的，有不懂的問我就行」，到后來國企的運營部也來找我提需求，真的是人人都是產品經理啊!

團隊里沒有專門的測試同事，都是上線那天一起加班，國企運營部的人幫忙測試，我們開發就在旁邊實時解決測出來的問題，順利的話當天發布，要是有遇到解決不了的bug就結束加班，明天繼續。

這個項目經過我手之后寫的是又大又爛，現在的我也看不下去那些代碼了，這個項目在我走之后也下線了。

在這家公司，我從跟甲方博弈，到跟產品經理撕逼，再到前端后臺數據庫服務器，全搞了一遍。不得不說這也是一個難得的學習機會，但是我在下一家公司嘗了這家公司帶給我的苦。

②技術型公司

一年后來到了這家公司，這家公司是數倉行業的標桿，產品是To B的，客戶都是各領域的KOL，又是中國的一個Apache開源項目，無論是技術還是開發流程規范說領先的應該不過分。

先看看我們的開發流程和規范：

1.PRD/issue

如果是新功能，而且相對比較大的，需要產品經理畫出原型圖以及詳細說明清楚;如果是bug或者比較小的功能，需要在github的issue上說清楚?？陬^說的永遠無效，如果產品經理口頭對我們說什么，我們都會要求他給文檔、發郵件或者在issue上說明清楚，也是保留證據，防止互相甩鍋。

2.本地Reproduce

本地重現bug。也就是出現bug的時候，我們開發要進行本地重現，只有重現出來才能從根本上解決問題。這一步是最難的，也是耗時最長的。如果連bug本地重現也重現不出來，后續工作基本難以進行。

3. 定位Root cause

對于Bug，我們要先找到引起的根本原因，這塊最考驗綜合能力。mentor給我的箴言就是：「大膽假設，小心求證」。 把所有可能性列出來，然后一個個去證實。只有定位了Root cause，你才能開始去寫代碼。

4.Design review

這是代碼架構設計上的一個review，是跟mentor或者leader對接確認的，在編寫代碼之前完成，避免設計不行，被全部推翻。這塊也要寫在github的issue，一方面為后人留下痕跡，便于后面維護或者迭代復盤。而且高層也經常翻閱issue，design review做的不好，也會被指出來，及時發現問題。

5.代碼編寫(阿里巴巴手冊，UT，IT)

寫好代碼是新手的基本要求，不寫低質量代碼。這邊要求按照effect java以及阿里巴巴代碼手冊進行約束，以及每寫完代碼都要通過UT或者IT進行覆蓋。

6.Test plan

當你寫完代碼之后，你需要制定一個測試計劃，也就是測試用例，去解決之前相同操作下會出現的bug或者驗證你的新功能。

7.Test evidence

也就是Test plan制定完之后進行實施，將驗證成功的截圖進行保留，貼到issue，作為你完成功能的證據。

8.CI

Continuous Integration-持續集成服務，它會自己運行構建和測試，反饋過程中是否存在Bug或者其他問題，看是否與我們預期的結果一致。我們是在Jenkins上完成的，當你的代碼有點改動你就需要去跑CI，避免影響到系統的其他模塊。

9.Code review

當你寫完代碼并且通過測試之后，通過pr的方式先給導師review，導師review完之后提交給leader，對于一些比較重要的模塊，在leader看完代碼之后還要進一步提交給CTO?？赐赀@個你還敢提交爛代碼?別說爛代碼了，一個變量名定義的不好都得被打回來。

剛開始入職的時候覺得這些操作很煩，改一行代碼就得去issue上面寫一堆，而且也要跑個幾小時的CI。當后來吃了幾次虧，真香。別看除了代碼編寫還有很多其他操作，其他操作也是為了讓你更好地去編寫代碼，幫你梳理整個開發流程，也不自覺地提升你工作的嚴謹性。所以到現在，我來公司解決的第一個bug，我都還知道Root cause，以及其他細節。其他人也知道，因為我都貼在issue上面。

由于我在第一段工作中養成很多不好的習慣，比如說代碼寫的又快又爛，debug各種log亂打，為了實現功能破壞了設計模式等等。所以在第二段工作經歷中被罵的狗血淋頭，國慶7天看了4本關于代碼設計的書籍并做了總結，對項目源碼進行深入閱讀，學習一些設計模式等等。

在第二家公司，雖然被懟了很多，但是收獲非常大，可以看我在第三家的表現。

③業務驅動型

業務驅動型的公司處于外包和技術型之間，也是以實現功能為主，又要注重后期維護，對規范處于中立狀態，不挖坑，不矯情。

由于我從第二家公司出來后，對代碼有一定的潔癖，所以到了第三家公司一有空就重構項目代碼，leader也贊同我的行為，經常找我聊代碼設計和規范。我也主動申請要補充部門的開發流程規范，數據庫的字段規范，并補全項目代碼的UT、IT等等。這也是我能提前轉正的原因之一。

四、如何在不同類型的公司提高核心競爭力

在外包公司，不能局限于一個點進行開發，外包公司需要的是全能型人才，哪里缺哪里補上。在外包公司不需要你技術多厲害，但需要你會利用現成的資源以最快的速度完成項目開發。你會的方面越多，公司需要你的地方也就越多，你得到的也更多。

在技術型公司，不需要你會的有多廣，你只需要針對公司產品的一個點進行深入了解，不斷地進行優化，這個點就是你的核心競爭力。再由這個點切入到相關模塊，技術深度才是王道。

在業務驅動型公司，不能光會技術，當其他開發人員只會跟老板講技術，而你能將具體技術落實到業務，并且能從業務層面反推到技術實現，老板能不喜歡嗎?但也要記住，技術是生存之道，別顧此失彼，耍小聰明。

技術人員的核心競爭力終究是技術，但技術也分廣度、深度、與業務結合的能力，在不同的環境下，應該學會取舍。

五、一些中肯建議

1.外包公司能不能去?

在沒有更好的選擇下，能去，有總比沒有好。并不是所以的外包公司都是一個模樣，說不定你的leader好，服務的又是又好又有錢的甲方，好吃好喝好款待。但大部分的外包還是不咋地，這邊調查好背景就行。

2.技術型公司哪里找?

所有開源項目背后的公司都是技術型公司。比如開源Kylin的Kyligence，開源Dubbo、RocketMQ的阿里、開源Flutter的谷歌等等。而像阿里、騰訊這種大公司，每個BU就是一個類型的小公司，有些負責技術，有些負責業務，有些外包。

3.對于應屆生的選擇?

建議去技術型公司或者核心技術部門。從我的案例就可以看到，技術型公司對我一個整體的塑造幫助最大，可能貫徹職業生涯。當你習慣了低標準的東西久了，就很難對高標準產生興趣。

4.我對于這三種公司的看法?

對于外包公司來說，我覺得會缺失「歸屬感」和「認同感」，畢竟做的不是自家的產品，還得去客戶現場駐扎，而且對于外包的技術也是不太看好。

對于技術型公司來說，對于個人成長幫助絕對很大，但在這種公司由于周圍都是level比你高的人，解決的問題也都是比較難的，所以無形中會有壓力并且會產生焦慮。

對于業務型公司來說，最好是選擇你比較擅長的并且有相關工作經驗的業務。我第一段實習做的是電商項目，所以我現在的工作也是找的電商，畢竟業務邏輯都是相通的，就算之后跳槽，也會選擇電商行業，畢竟除了技術，行業知識也是競爭力之一。

選什么類型公司，仁者見仁，可以根據自己的興趣以及擅長的地方做選擇。