“垃圾的業務邏輯！！！” 估計很多程序員在剛接觸一個新項目的業務代碼的時候，都會在心裡罵娘，說不準已經把前幾任維護者的家人都給問候了一遍。
在我自己的職業生涯裡面，也遇到過不少寫得跟 “屎” 一樣的業務代碼，但業務代碼，業務邏輯是一個程序員不可避免要接觸的東西。
按 “二八原則”， 估計有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 的產品，業務技術經驗是企業級應用，比如如何在共性需求和個性需求之間進行取捨。
搜索，電商等都是如此。
以上的這些業務技術經驗都是有很高技術經驗壁壘的，一旦你積累起來，後面就是獵頭來挖你了。
跟挖人的獵頭接觸的時候，他們喜歡問，你有沒有做社交產品的經驗，你有沒有做過搜索系統，做過推薦系統，有沒有做過企業級的應用等。
挖人的獵頭，招聘的面試官，都希望能夠找到有相關經驗的從業者，而客觀來說，行業經驗的壁壘比技術棧的壁壘要高很多。
新的技術棧，你可能花幾個月的時間，就可以掌握到一定程度了，但行業經驗，卻是要經年累月積累的。
所以，你在做職業規劃的時候，一定要認真思考這個問題，自己所在的行業是什麼，未來可選擇的有哪些公司，自己應該注重積累哪些業務技術經驗
。最後
技術服務於業務，這是客觀存在的，不過隨著技術的發展和存量時代的到來，技術人員的決策權會越來越大。
踩坑，閱讀噁心的業務邏輯代碼，是一件很有價值的事情，很多人不願意做，但做的人，可以獲得一份獨到的經驗，這個便是競爭的壁壘。
做業務的同學，平日要多思考，多總結，嘗試思考業務的共性，思考業務的標準化，這能夠極大的提高自身軟件設計的能力。
職業發展的規劃，是個開放性的問題，我的建議是圍繞業務技術經驗做職業規劃，而非圍繞技術棧做職業規劃。
原文完
Android 研習(襲)社 事件更新：
發出文章後得到了很多人的幫助，感謝大家支持。
另外有點意外的是，從各個地方得到了更多關於 Android 研習(襲)社的黑料
，新增了個角色，叫「路遙」，他們一起幹了些破事，手段骯髒，極其不要臉，聽了想打人的那種，讓我長見識了。不過平時我都挺忙的，要看到這些內容得等等了，困了 睡覺去了。
Have a good day!
