Time will tell.
前言
“垃圾的業務邏輯！” 估計很多程式員在剛接觸一個新專案的業務代碼的時候，都會在心里暗罵，說不準已經把前幾任維護者的家人都給問候了一遍，
在我自己的職業生涯里面，也遇到過不少寫得跟 “屎” 一樣的業務代碼，但業務代碼，業務邏輯是一個程式員不可避免要接觸的東西，
按 “二八原則”， 估計有80%的程式員是業務開發，而事實上，我覺得這個比例可能要到90%， 畢竟系統工程師，基礎架構工程師，業務組件開發工程師等純技術的崗位是很少的，當然這些 “純” 技術崗位，也非完全不接觸業務，只是上比例更少而已，
可以說，90%的程式員，職業生涯里80%的時間都是在跟業務打交道的，所以我們很有必要探討一下這個話題，
1. 技術服務于業務
純技術驅動的公司，我覺得是不存在的，只不過有些公司的技術氛圍會更好，技術人員的決策權會更大，
在目前的市場上， 產品+技術， 市場+技術 是比較正常的企業結構模式，至于技術人員在不同公司里面權重的大小，就要看具體情況了，
像騰訊是產品驅動的公司，阿里是電商，更多由市場驅動，一個是消費者市場，一個是商家市場；拼多多跟阿里類似，頭條其實也是產品驅動的公司；美團由消費者市場驅動，小米賣的是產品，百度的搜索由消費者驅動，AI由企業市場驅動，
當然，這里不是說技術就只能從屬于其它崗位了，目前很多企業對技術人員的重視度是越來越高的，而技術人員在實際作業中的決策權也在加大，我覺得這個跟技術的發展有關，
比如說，目前在市面上火爆的推薦型產品，如頭條，抖音，技術在里面的決策比重就要比一般性產品的高，這個很好理解，因為產品形態本身就很依賴于技術，雖然產品的互動體驗，UI 設計依然很重要，但最關鍵的還是你推薦出來的東西，用戶有沒有興趣，而推薦這部分，就是技術驅動的，
還有一類是 AI型的產品，比如商湯科技，沐瞳科技這類，他們銷售的是自身的AI能力，雖然還是市場主導，但技術在里面會有更多的決策權，
未來，我相信隨著技術的發展，AI化的產品會越來越多，技術人員在里面的決策權也會越來越大，另外，隨著存量時代的到來，從增量市場進入到了存量市場，增量時代比拼的是快，存量市場比拼的是品質，這里的品質包括產品品質，也包括企業品質(高效的運作模式)，這必然對技術提出更高的要求，技術人員在決策上的比重也自然會增加，
2. 踩坑，閱讀惡心的業務邏輯代碼，是不是一件有價值的事情？
以上依然是不可避免的一件事情，在你實際面對那些惡心的業務邏輯代碼的時候，你必定要吐槽一番，然后開始陷入深深的自我懷疑：＂我這是在干什么？簡直是在浪費時間！＂
12年做存盤的時候，我們遇到了一個問題，存盤系統搞完了，卻沒有業務愿意接進來，
他們說，你的系統不穩定，而且性能也沒有特別好（早期版本），為什么要接？以上的反問，我也無可辯駁，但專案還是要向前推進，后來我們決定這些事情都由我們自己來搞，
于是我找了具體業務的負責人，跟他們說，我們來修改業務代碼接入新的存盤系統，中間程序如果出了問題，責任都算我們的，
第一批的業務，就靠這種方式推動起來了，
后面，我加入到業務團隊后，第一接手的，是個核心但卻惡心的業務系統，當時那個系統極不穩定，經常出問題，但上面下了死命令，你們就是要搞好，要不，你們團隊就沒有存在的價值！
于是噼噼啪啪，整了兩個多月的時間，重構了很多的業務邏輯，才慢慢好起來，
我的實際經驗是：踩坑，看惡心的代碼本身，不會產生很大的價值，但是踩坑的程序中獲得的經驗，看惡心代碼，修改惡心代碼的程序中獲得的負反饋，卻極有價值，
它們雖然沒有給你展示什么是好的，但是給你展示了什么是不好的，這程序中，你會慢慢明白，你應該怎么做，才不會重蹈前人的覆轍，
3. 終日跟業務打交道，應該如何來提升自己
學會思考和總結
比如當 if else 寫得太長的時候，是不是分析下判斷條件的內在邏輯，有沒有可能去構建一個狀態機，
比如一段代碼邏輯，當你寫第二次的時候，是不是考慮抽成一個單獨的函式，因為有第二次，就意味著會有第三次，第四次，
有不少同學覺得業務邏輯繁雜且沒有技術含量，所以一直對業務邏輯有抵觸的心理，但實際上，業務邏輯也不完全是無章可循，不可復用的，
如果你留心觀察市面上的各類產品，各種APP，你會發現，大家在功能上都會有很多的相同點，
比如，每個APP，幾乎都會有這些功能：注冊，登錄，用戶頭像，昵稱，用戶資料管理，
有些APP會有訊息聊天，有的APP會有論壇功能，有的APP會有內容推送，有的APP會有商城，會有支付，
總的來說，你可以認為To C 產品的業務邏輯是有限的( To B的業務豐富性會更高，但也是有限的)，雖然具體的業務邏輯不同，但設計的關鍵點，其實是相同的，
比如說登錄，一個產品的登錄模塊，一般會涉及：就近接入，IP重定向，加密設計，密碼驗證等，
比如說訊息邏輯，訊息邏輯的關鍵點一般是：訊息的唯一性和順序性，
類似論壇，內容推送，商城，支付，都一樣，每個具體的業務都有其關鍵點，而且這些關鍵點幾乎都有業內最佳實踐，也有很高的經驗可復用性，(代碼不一定可以復用，但設計思路幾乎都是相同的)，
所以這里一定要學會思考和總結，你的成長只能你做主，沒人可以幫你！
不要只守著自己的一畝三分地
很多人做事，只守著自己一畝三分地，來一個需求，做一個需求，做完就不理了，不愿意進行更多的總結，也不愿意接觸需求以外的代碼和邏輯，
一個超過５人維護的系統，就可以認為是一個大系統了，這類系統，按一般比例，有 80％ 的邏輯不是你維護的，所以這里就是關鍵了，有的人會去了解覆寫面更廣的剩余的 80％ 的邏輯，有的人就終日只守著自己那塊，
所以最終，一定是更愿意了解全盤的人可以勝出，升職加薪，開始負責統籌整個專案，
這個道理很淺顯的，只是很多人或懶或不屑去做，但人跟人的差距，確實就是在這些額外的付出中拉開的，
圍繞業務經驗規劃職業發展
我發現不少同學的職業規劃有點問題，有些人是圍繞新技術來規劃自己的職業發展的，這顯然有問題了，這么做的結果，就是終日在追新技術，終日焦慮，但卻沒有形成核心的競爭力，
我覺得業務的同學應該圍繞業務技術經驗來規劃自身的發展
其實大家日常接觸的所有需求，延展開來看，都是跟一個具體的行業相關的，
比如做微信，QQ，是 To C 的產品，再細分是社交產品，業務技術經驗是社交架構和海量服務，
頭條，抖音，是推薦型產品，業務技術經驗是推薦系統，
企業級應用，SaaS，是 To B 的產品，業務技術經驗是企業級應用，比如如何在共性需求和個性需求之間進行取舍，
搜索，電商等都是如此，
以上的這些業務技術經驗都是有很高技術經驗壁壘的，一旦你積累起來，后面就是獵頭來挖你了，
跟挖人的獵頭接觸的時候，他們喜歡問，你有沒有做社交產品的經驗，你有沒有做過搜索系統，做過推薦系統，有沒有做過企業級的應用等，
挖人的獵頭，招聘的面試官，都希望能夠找到有相關經驗的從業者，而客觀來說，行業經驗的壁壘比技術堆疊的壁壘要高很多，
新的技術堆疊，你可能花幾個月的時間，就可以掌握到一定程度了，但行業經驗，卻是要經年累月積累的，
所以，你在做職業規劃的時候，一定要認真思考這個問題，自己所在的行業是什么，未來可選擇的有哪些公司，自己應該注重積累哪些業務技術經驗，
最后
技術服務于業務，這是客觀存在的，不過隨著技術的發展和存量時代的到來，技術人員的決策權會越來越大，踩坑，閱讀惡心的業務邏輯代碼，是一件很有價值的事情，很多人不愿意做，但做的人，可以獲得一份獨到的經驗，這個便是競爭的壁壘，
做業務的同學，平日要多思考，多總結，嘗試思考業務的共性，思考業務的標準化，這能夠極大的提高自身軟體設計的能力，職業發展的規劃，是個開放性的問題，我的建議是圍繞業務技術經驗做職業規劃，而非圍繞技術堆疊做職業規劃，
絮叨
如果你對面試題、軟體、介面、自動化測驗、python感興趣的可以加入我們175317069一起學習喔，群內會有不定期測驗資料鏈接發放，
喜歡的話，歡迎【評論】、【點贊】、【關注】禮貌三連
Time will tell.（時間會證明一切）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/162331.html
標籤：其他
上一篇：【軟體測驗】學習書籍推薦！
下一篇：軟體測驗人員的發展誤區