這篇文章是一位好朋友的投稿，記錄了他跳槽之后的一段奇妙的經歷。非常有意思，一定要看到最后！！！

下面是正文。

11 月下旬入職新公司到現在也已經有一個半月的時間了，入職前，各種擔心適應不了新公司，新項目的技術框架、業務流程，入職后才發現，現在手頭的這碗飯，真的要好好感謝上一任。感謝他，讓現在公司部門里的同事，覺得我是個大神...

項目背景

我新入職的是一家上市公司，有自己龐大的實體產業，但對軟件技術要求不高，什么高并發分布式，花里胡哨的，謝絕。內部很多軟件用的都是第三方公司開發的成熟 ERP，頂多做做二次開發，唯獨我現在接手的這個項目是前任耗時三個多月，前后端一肩挑從零開發的（其實這個周期挺緊的），是的，你沒聽錯，一個人做了一個項目。

你可能會問我為什么要進這種公司，其實我的想法很簡單，這家公司雖然給的薪資不算高（現在明顯覺得工資要低了，o(╥﹏╥)o），但日常工作作息 855，制度規范，況且我身處三線城市，別說中廠大廠，小廠都沒有....

扯遠了，以上是項目背景，接下來說說項目使用的框架。

項目框架

當我小心翼翼問技術總監使用什么框架的時候，總監給我的答案是，前端 H-UI，后端用 springboot。

后端我熟，干 java 誰不用 springboot，就是這個 HUI 是什么鬼，怎么不是 vue 之類的東西，然后特意去百度了下，好家伙，還像模像樣的，可能是我孤陋寡聞了，從沒聽說過

其他呢，比如中間件之類的，沒有嗎？redis 總有吧，沒有！

隱隱約約我有種不祥的預感

項目上手

入職的第一天，公司發了臺 thinkpad，前任留下的，打開的時候桌面密密麻麻一片，有各種文件夾，安裝包，更多的是，一個個 java 文件！！！？？？？

為什么會有這么多 java 文件放在桌面上，什么鬼

后面我就懂了，這個 B 沒用版本管理，別說 git 了，svn 都沒有，所以桌面上的 java 文件都是他的手動備份...

而且這臺電腦前任雖然用過，但是很新，很多開發必備的工具都沒有，一問才知道他嫌棄這臺電腦配置不行，我一臉懵逼，16G+I5 九代+固態，不算很好但對開發來講也不錯了吧，后面項目實施一臉無奈的告訴我，他喜歡用隔壁辦公桌上那臺 64G 內存 i7 處理器的臺式機（平常用來做虛擬機的），wtf？

在看完他留下的 5 個交接錄制視頻+還有兩天項目實施給我講解業務之后，開始上手接收項目

吐槽

因為三個多月這家公司沒招到合適的人，積壓了很多緊急 bug&需求需要處理，事情很急，但我發現在開始碼代碼之前，有太多的事情得準備....

重要信息記錄

給我的文檔上就寥寥幾行字，一些服務器的地址，賬號密碼，對這個項目的介紹基本都放在視頻里了，而且視頻本身講的也很草率，所以等解決完緊急 bug 和需求后，需要對這個項目進行必要的總結和技術整理，形成文檔，萬一哪天我也離職了，后人可以翻閱填坑。

版本管理

之前說到沒有版本管理，看著桌面上一堆 java 文件，所以第一件事就是在內網搭了 gitlab，把所有的項目傳了上去，傳完的那一刻長吁了一口氣，先不說平時寫代碼切分支有多方便，至少不用擔心如果筆記本炸了代碼丟了怎么辦的問題......

數據庫設計

當我打開數據庫的時候發現，所有的表，所有的字段都沒有備注，所以趕緊跟項目實施對了一下午的數據庫，全部加上了注釋（謝天謝地，至少還留了一個懂項目的實施）

在盤數據庫的過程中，我痛苦的發現他的數據庫設計完全不按章法，比如日期類型用 varchar，一些 varchar 字段長度設置 1000（以為這樣可以容納更長的數據？？？？），一些金額、數量字段也用 varchar，有一張表居然全部用了 varchar！！！

真不知道 varchar 上輩子是他的情人還是救了他全家人的命

除此之外，還有一個細節也被我注意到了：沒有一張表是加索引的，這個問題后面會說到

代碼注釋

這個是我接手這個項目最痛苦的地方，往往一個處理方法兩三千行（是的，你沒看錯），光禿禿的，沒！有！一！行！注！釋！

“我平生最恨兩種人，一種是不寫注釋的，另一種，是逼我寫注釋的”

有一塊業務邏輯是計算月工資，很復雜，各種計件，補貼，考勤，扣款融合算，我相信上任寫這塊代碼的時候也是心情崩潰的，但他的崩潰跟我的崩潰可能不太一樣，我的崩潰是：為什么明明這么清楚的邏輯要寫的這么復雜！！！明明可以把之前的代碼優化下非要用更饒的邏輯去圓已經繞到卷毛的代碼！！！

吐槽歸吐槽，崩潰的我一行一行讀代碼，時不時的問問項目實施，隔幾行就寫注釋，邊注釋邊改，勉強度日，想起那些年我做英語閱讀理解的日子。

PS：我平時還是比較習慣寫注釋的，因為很多復雜的邏輯不寫注釋，后面連自己都會忘記

命名規范、變量定義

我根本不用擔心貼代碼會造成信息泄露什么的，大家隨便看，能看懂算我輸

雖然命名是一件頭疼的事情，但這么隨意合適嗎？還有下面這類神仙代碼，你根本不知道這里面的 21.75，10，15 都是代表什么意思，這里的操作是為了干什么，如果沒有懂業務的實施跟我講的話真不知道該怎么辦。

代碼抽象、封裝

說實話，這要求對于上任屬實有點高，不然也不會出現幾千行的直腸子代碼，你們看看上面貼的代碼心里就會明白，為什么代碼又臭又長。

我的看法是，一個處理代碼行數超過四五十行，就可以考慮縮減抽離了，為什么要這么做，其實很簡單：出于可維護性。一個業務再復雜，離不開一個主干邏輯（也可能是多個）和 N 個子邏輯，你不能把臃腫的子邏輯代碼放在同一個處理代碼內部，這樣太影響可讀性，影響可讀性的后果就是提高了維護成本。

往往得到一個變量后，我得隔個幾十行甚至一兩百行才能找到用到它的地方

.....主處理一子處理1（假設這里有幾百行代碼）主處理二子處理2（假設這里有幾百行代碼） 子處理3（假設這里有幾百行代碼）主處理結束....

數據查詢處理

前任寫數據庫查詢，大部分都使用 tk.mybatis 做快速查詢、修改之類，跟 mybatis plus 有點類似，這本身沒什么毛病，都為了提高代碼效率，但我很想吐槽的是，明明很好的工具，卻被他用的很廢：

List<實體類> a = 快速查詢全部 List<實體類> b = 快速查詢全部 List<實體類> c = 快速查詢全部 List<實體類> d = 快速查詢全部 ....然后對a、b、c、d一通過濾，然后瞎雞兒算

現在很多公司，確實因為數據量大的問題，會提倡單表查詢，復雜的數據處理都放在 service 層進行，但問題是，從持久層出來的數據應該是經過篩選的，精簡數據量。但他沒這么做，不管三七二十一，先全部取出來再慢慢用 java 過濾。

而且，這套算工資的系統數據量并不大，現在運行半年了，數據量最大的那張表只有 40 多萬（日志表不算），再加上計算工資邏輯復雜，雖然需要關聯的表多，如果能夠妥善加好索引，在持久層就定義好數據結構，把想要的原始數據處理好，那么邏輯處理也會簡單許多。

img

上個月算工資的那幾天是最忙的，為什么？因為財務各種反饋接口速度慢，幾分鐘那是正常的，運行十多、二十多分鐘也有，我花了兩天時間重構了其中一個核心分支，關聯兩三表，建好索引，只取需要的字段，重新定義持久層返回的數據結構，最終把需要花五六分鐘的這部分處理縮減為幾秒，但總的接口處理還是很慢，后續還要花時間去優化（感謝前任讓我有做不完的事情）。

數據入庫處理

這部分，我不說話，大家看圖

代碼里充斥著大量的循環插入數據庫這種做法，管你是幾千幾萬條數據，勞資就是這么入庫的，一年工作經驗的都不會犯這種錯誤吧。

前端列表分頁

前端用的 H-ui，先不評判這個框架好不好，但用戶反應最多的就是：卡，卡，卡 我一開始是以為是接口問題，雖然發現接口確實很慢，但數據查詢完畢返回后頁面上還是沒有加載出來，后面才發現，一次接收的數據足足有 40 多 m.....

這個 B 沒做物理分頁！

而且他前端渲染表格的方式是這樣的，手動拼接字符串然后填充到網頁里

在了解 H-UI 是基于 bootstrap 開發之后，我果斷用了 bootstrap-table 去重構前端渲染方式，至少頁面這個時候可以渲染出來的，雖然接口還是慢。

而且多刷新幾次頁面之后，瀏覽器內存爆表，性能差一點的電腦直接 GG，怎么辦？換成物理分頁唄，又增加了許多的無端工作量。

但這么多的頁面我也不可能全部換成物理分頁，只能調問題比較嚴重的頁面進行優化，因為還有那么多 bug 和需求等著我呢....

接口、服務地址切換

這個項目有需要跟第三方系統交互的場景，所以涉及到測試接口、正式接口，然后我發現下面這種現象：

String str_url = 本地測試地址; //String str_url = 正式地址;

有一個 bug 是因為他測試時忘記切回正式接口地址然后發布到了生產環境導致的...

這種測試的時候忘記切回其實也是一種正常現象，但我們可以通過代碼去規避啊，比如把這種 url 參數放到配置文件里，測試環境自動用測試配置文件，生產環境用生產環境的配置文件（原先只有一個 application.yml 文件），還用擔心忘記切回的問題嗎？

而且為了避免發版出現人為的疏忽錯誤，我順便搭了 jenkins 自動化部署，這樣就不用擔心萬一哪天配置文件忘記切到正確環境而引起的災難性后果。

是人就會犯錯，但有工具可以幫你規避，只是前任懶得弄這些。

其他的，redis，log4j2 等一些項目必備工具就不說了，該加的我都加上去了。

工作態度

說一說跟這個行業沒直接關聯的，職業態度。據同事們講，平時給他的需求很多都以不能做，做不了為由拒絕，在提出離職后的一個月內，沒有修改任何的 bug，完成任何的需求，一直在進行所謂的學習（因為我看到隔壁座位上開了 N 個虛擬機，估計在練集群分布式唬住面試官之類的技術），可能有些人要跟我爭論，都打算離職了操這么多心干什么，抱歉，可能我的想法是公司最后一個月也是足額付你工資的，至少我離職的時候也是勤勤懇懇解決當前的 bug、寫完交接文檔后再走的，直到現在，前同事問我項目上的問題也都是一一解答。

現在 IT 行業很卷，干我們這行的也很辛苦，還要面臨公司的剝削和壓榨，所以出現很多摸魚黨，這其實也是一種自我保護，畢竟命是自己的，錢就這么點，那么拼干什么。但話說回來，職業道德還是要有，最基本的底線得守住，該摸魚摸魚，該上的時候也得上，又不是體制內，能混多久?（個人愚見，所以老板真的也非常喜歡我這種低薪又肯干的老黃牛員工）

致謝

現在的同事潛意識里都覺得我是個非常厲害的技術大佬，但有經驗的程序員看到上面我所說的東西都會嗤之以鼻，這些不都是基操嗎，還有人要強調這個？我以前也覺得在三四線城市，大家技術水平應該也差不多，好不會好到哪去，差也不會差到哪去，這次的跳槽真讓我開闊了眼界。

所以在感慨，在這個行業可能確實需要像前任這樣的碼農，挖坑，填坑，坑更多了，再填......生生不息，這樣行業才能長久生存，沒有 bug 可以修復，沒有屎山可以鏟，我們真的就失業了。如果每個程序員寫的文檔詳細，邏輯清晰，注釋清楚，拿什么讓老板離不開你，靠什么威脅老板給你高工資，所以我現在的處境用一句話形容：

全憑同行襯托

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的感谢前任程序员赏饭吃！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。