作者：大飛哥

“垃圾的業務邏輯！??！” 估計很多程序員在剛接觸一個新項目的業務代碼的時候，都會在心里罵娘，說不準已經把前幾任維護者的家人都給問候了一遍。

在我自己的職業生涯里面，也遇到過不少寫得跟 “屎” 一樣的業務代碼，但業務代碼，業務邏輯是一個程序員不可避免要接觸的東西。

按 “二八原則”， 估計有80%的程序員是業務開發，而事實上，我覺得這個比例可能要到90%， 畢竟系統工程師，基礎架構工程師，業務組件開發工程師等純技術的崗位是很少的，當然這些 “純” 技術崗位，也非完全不接觸業務，只是上比例更少而已。

可以說，90%的程序員，職業生涯里80%的時間都是在跟業務打交道的，所以我們很有必要探討一下這個話題。

技術服務于業務

純技術驅動的公司，我覺得是不存在的，只不過有些公司的技術氛圍會更好，技術人員的決策權會更大。

在目前的市場上， 產品+技術， 市場+技術 是比較正常的企業結構模式，至于技術人員在不同公司里面權重的大小，就要看具體情況了。

像騰訊是產品驅動的公司，阿里是電商，更多由市場驅動，一個是消費者市場，一個是商家市場；拼多多跟阿里類似，頭條其實也是產品驅動的公司；美團由消費者市場驅動，小米賣的是產品，百度的搜索由消費者驅動，AI由企業市場驅動。

當然，這里不是說技術就只能從屬于其它崗位了，目前很多企業對技術人員的重視度是越來越高的，而技術人員在實際工作中的決策權也在加大。我覺得這個跟技術的發展有關。

比如說，目前在市面上火爆的推薦型產品，如頭條，抖音，技術在里面的決策比重就要比一般性產品的高。這個很好理解，因為產品形態本身就很依賴于技術，雖然產品的交互體驗，UI 設計依然很重要，但最關鍵的還是你推薦出來的東西，用戶有沒有興趣，而推薦這部分，就是技術驅動的。

還有一類是 AI型的產品，比如商湯科技，沐瞳科技這類，他們銷售的是自身的AI能力，雖然還是市場主導，但技術在里面會有更多的決策權。

未來，我相信隨著技術的發展，AI化的產品會越來越多，技術人員在里面的決策權也會越來越大。

另外，隨著存量時代的到來，從增量市場進入到了存量市場。增量時代比拼的是快，存量市場比拼的是品質，這里的品質包括產品品質，也包括企業品質(高效的運作模式)，這必然對技術提出更高的要求，技術人員在決策上的比重也自然會增加。

踩坑，閱讀惡心的業務邏輯代碼，是不是一件有價值的事情?

以上依然是不可避免的一件事情，在你實際面對那些惡心的業務邏輯代碼的時候，你必定要吐槽一番，然后開始陷入深深的自我懷疑：＂我這是在干什么？簡直是在浪費時間！＂

12年做存儲的時候，我們遇到了一個問題，存儲系統搞完了，卻沒有業務愿意接進來。

他們說，你的系統不穩定，而且性能也沒有特別好（早期版本），為什么要接？

以上的反問，我也無可辯駁，但項目還是要向前推進，后來我們決定這些事情都由我們自己來搞。

于是我找了具體業務的負責人，跟他們說，我們來修改業務代碼接入新的存儲系統，中間過程如果出了問題，責任都算我們的。

第一批的業務，就靠這種方式推動起來了。

后面，我加入到業務團隊后，第一接手的，是個核心但卻惡心的業務系統，當時那個系統極不穩定，經常出問題，但上面下了死命令，你們就是要搞好，要不，你們團隊就沒有存在的價值！

于是噼噼啪啪，整了兩個多月的時間，重構了很多的業務邏輯，才慢慢好起來。

我的實際經驗是：踩坑，看惡心的代碼本身，不會產生很大的價值，但是踩坑的過程中獲得的經驗，看惡心代碼，修改惡心代碼的過程中獲得的負反饋，卻極有價值。

它們雖然沒有給你展示什么是好的，但是給你展示了什么是不好的，這過程中，你會慢慢明白，你應該怎么做，才不會重蹈前人的覆轍。

終日跟業務打交道，應該如何來提升自己

１、學會思考和總結

比如當 if else 寫得太長的時候，是不是分析下判斷條件的內在邏輯，有沒有可能去構建一個狀態機。

比如一段代碼邏輯，當你寫第二次的時候，是不是考慮抽成一個單獨的函數，因為有第二次，就意味著會有第三次，第四次。

有不少同學覺得業務邏輯繁雜且沒有技術含量，所以一直對業務邏輯有抵觸的心理，但實際上，業務邏輯也不完全是無章可循，不可復用的。

如果你留心觀察市面上的各類產品，各種App，你會發現，大家在功能上都會有很多的相同點。

比如，每個APP，幾乎都會有這些功能：注冊，登錄，用戶頭像，昵稱，用戶資料管理。

有些APP會有消息聊天，有的APP會有論壇功能，有的APP會有內容推送，有的APP會有商城，會有支付。

總的來說，你可以認為To C 產品的業務邏輯是有限的( To B的業務豐富性會更高，但也是有限的)，雖然具體的業務邏輯不同，但設計的關鍵點，其實是相同的。

比如說登錄。一個產品的登錄模塊，一般會涉及：就近接入，IP重定向，加密設計，密碼驗證等。

比如說消息邏輯，消息邏輯的關鍵點一般是：消息的唯一性和順序性。

類似論壇，內容推送，商城，支付，都一樣，每個具體的業務都有其關鍵點，而且這些關鍵點幾乎都有業內最佳實踐，也有很高的經驗可復用性。(代碼不一定可以復用，但設計思路幾乎都是相同的)。

所以這里一定要學會思考和總結，你的成長只能你做主，沒人可以幫你！

２、不要只守著自己的一畝三分地

很多人做事，只守著自己一畝三分地，來一個需求，做一個需求，做完就不理了，不愿意進行更多的總結，也不愿意接觸需求以外的代碼和邏輯。

一個超過５人維護的系統，就可以認為是一個大系統了。這類系統，按一般比例，有 80％ 的邏輯不是你維護的，所以這里就是關鍵了。有的人會去了解覆蓋面更廣的剩余的 80％ 的邏輯，有的人就終日只守著自己那塊。

所以最終，一定是更愿意了解全盤的人可以勝出，升職加薪，開始負責統籌整個項目。

這個道理很淺顯的，只是很多人或懶或不屑去做，但人跟人的差距，確實就是在這些額外的付出中拉開的。

圍繞業務經驗規劃職業發展

我發現不少同學的職業規劃有點問題，有些人是圍繞新技術來規劃自己的職業發展的，這顯然有問題了。這么做的結果，就是終日在追新技術，終日焦慮，但卻沒有形成核心的競爭力。

我覺得業務的同學應該圍繞業務技術經驗來規劃自身的發展。

其實大家日常接觸的所有需求，延展開來看，都是跟一個具體的行業相關的。

比如做微信，QQ，是 To C 的產品，再細分是社交產品，業務技術經驗是社交架構和海量服務。

頭條，抖音，是推薦型產品，業務技術經驗是推薦系統。

企業級應用，SaaS，是 To B 的產品，業務技術經驗是企業級應用，比如如何在共性需求和個性需求之間進行取舍。

搜索，電商等都是如此。

以上的這些業務技術經驗都是有很高技術經驗壁壘的，一旦你積累起來，后面就是獵頭來挖你了。

跟挖人的獵頭接觸的時候，他們喜歡問，你有沒有做社交產品的經驗，你有沒有做過搜索系統，做過推薦系統，有沒有做過企業級的應用等。

挖人的獵頭，招聘的面試官，都希望能夠找到有相關經驗的從業者，而客觀來說，行業經驗的壁壘比技術棧的壁壘要高很多。

新的技術棧，你可能花幾個月的時間，就可以掌握到一定程度了，但行業經驗，卻是要經年累月積累的。

所以，你在做職業規劃的時候，一定要認真思考這個問題，自己所在的行業是什么，未來可選擇的有哪些公司，自己應該注重積累哪些業務技術經驗。

最后

技術服務于業務，這是客觀存在的，不過隨著技術的發展和存量時代的到來，技術人員的決策權會越來越大。

踩坑，閱讀惡心的業務邏輯代碼，是一件很有價值的事情，很多人不愿意做，但做的人，可以獲得一份獨到的經驗，這個便是競爭的壁壘。

做業務的同學，平日要多思考，多總結，嘗試思考業務的共性，思考業務的標準化，這能夠極大的提高自身軟件設計的能力。

職業發展的規劃，是個開放性的問題，我的建議是圍繞業務技術經驗做職業規劃，而非圍繞技術棧做職業規劃。

感謝大家能耐著性子看完這篇文章