很多開發者為天天寫業務代碼無暇提升技術而焦慮、苦惱，比如：
又如：
又如：
再如：
那么，作為開發者，到底該怎么面對“寫業務代碼”這件事呢？
今天我們就從以下幾個方面聊聊這個話題：
- 什么是業務
- 業務和技術的關系
- 業務和因解決業務而衍生的業務
- 對業務的態度因你在團隊中的角色而不同
- 如何從寫業務代碼中跳出來，做你所謂的有技術含量的工作
我們先來看看，什么是業務。
1. 什么是業務
簡單講，“業務”就是需要處理的各種事務，但通常偏向指客戶實際作業涉及的事務，“業務”最終的目的是完成工作所做的所有事務。
比如取款就是一種業務，ATM 機內運轉的軟件，要解決的業務就是取款。
比如掛號、預約、查檢查報告，都是業務，趣醫網的 App 就可以用來解決這些業務。
比如買火車票也是業務，12306 這個網站就是為解決買車票的業務服務的。
2. 業務和技術的關系
軟件是用來解決現實世界中的業務給人們的工作帶來便利的。
比如到火車站買票，要坐車、提前、排隊，又麻煩又消耗時間又浪費精力，而 12306 網站和 App ，通過把買火車票這種現實業務虛擬化，為人們省去了奔波、排隊、耗時的麻煩。
比如大家都想到好醫院看病，人人都想掛專家號，很多人為了掛到某個醫生的號，通宵排隊，非常辛苦，而現在的各種網上掛號網站、微信公眾號、 App ，通過軟件技術手段，把專家大夫這種資源虛擬化，讓大家隨時隨地能掛號，還不用到醫院、不用通宵憋尿排隊、不用擔心被醫托和黃牛忽悠，給患者帶來了極大便利。
軟件是現實業務虛擬化的載體，技術最終是為了解決業務問題的。從這個角度講，所有的開發者，其工作最終都是指向某個特定業務問題的。沒有業務，技術的存在就沒有意義。技術不能解決實際問題，不能給人們帶來便利，就沒有價值。
但從另一方面來講，技術是現實業務虛擬化的必要條件，沒有技術，現實中的業務就無法被虛擬化。而且，同一種技術又可以實現多種業務的虛擬化。所以，很多初階的開發者才會有種“錯覺”：技術牛 X ，因為沒有技術就無法實現業務，業務很 Low ，技術牛 X 了，隨隨便便就能搞定。
實際上，這些感覺雖然在一定階段有其道理，但并不是真理哦。
關于業務和技術的關系，這里下個結論：
- 技術是為了解決業務問題的，只有在實現業務、給人們帶來便利的前提下，技術的存在才有意義，所以，多數時候，是業務決定技術、業務統領技術。
- 沒有技術，業務就無法被虛擬化，生產效率就很難有效提升
- 業務和技術具有相互促進、相互依存的關系。
我們回到開發者身上來看，寫業務代碼多一些，還是所謂的技術代碼多一些，沒有高下之分，只有個人取向和組織分工的不同。
3. 業務和因解決業務而衍生的業務
很多開發者會用割裂的眼光來看待業務和技術，比如把增刪改查（CRUD）看作是無意義的業務代碼，把實現 libuv 或 Redis 這樣的框架看作是有技術含量的事情。
比如京東上《程序員的成長課》這本書的詳情頁，是這樣的：
它對應的架構是這樣的：
很多開發者會覺得，寫那些用來展示《程序員的成長課》的圖書封面、優惠券、促銷等相關信息的代碼是沒什么技術含量的，因為那些是業務代碼。
他們會覺得，寫商品詳情頁架構中的 Redis、JMQ 或 JIMDB 是有技術含量的，是真正的技術代碼。
但實際上，所謂的業務代碼和技術代碼，它們的區別，僅僅是和業務的距離遠近不同而已：業務代碼離業務更近，技術代碼離業務稍遠。它們最終都是指向業務實現的。
而且，你換一種視角來看業務，就會發現，其實每一層代碼，都服務于它的上一層代碼，上一層代碼，就是它的業務！
比如詳情頁架構的第2層“對外提供API”中的商品介紹個 API ，它的服務對象，就是前端頁面，要解決的業務，就是“響應前端頁面的查詢，提供商品介紹”
而第2層底部的前端數據集群（JIMDB），它的服務對象，就是商品介紹，要解決的業務，就是“存儲商品或代理商品介紹信息”。
簡單說，每一層技術實現，都服務于上一層，都以上一層的需求為業務。從這個角度講，現實中的業務在被虛擬化的過程中，會在技術實現層面引發分層，產生中間性、對用戶不可見的新業務。
從這個廣義業務的視角來看，每一層代碼，都是業務代碼！
但是為什么很多開發者又覺得所做的技術實現越接近現實業務越沒技術含量呢？
這是因為，你越接近用戶業務：
- 細節越多，繁瑣度越高，越不容易做好，越容易因為一點小瑕疵而被否定，讓人覺得自己的勞動沒價值
- 現實性越強，變化幾率越高，越容易來回修改代碼，越讓人覺得自己的掌控感低下
- 實現的代碼可遷移性越差，勞動成果被復用的概率越低
而當你遠離用戶業務時：
- 你用到的技術，多數都是被高度抽象過的、用來解決從用戶業務衍生出的技術性業務的，它們比具體的用戶業務穩定，它們的適用面更廣，也更容易被遷移到其它的業務領域
- 你的勞動成果因為具有抽象屬性，被復用的概率會更高，你會更愿意打磨它，會更有成就感
- 你受到壓力，經過距離用戶近的幾層同事的傳遞，得到了衰減，沒那么大
- 你打交道的對象，多數時候是內部同事、是技術人群，更容易達成一致
4. 對業務的態度因你在團隊中的角色而不同
你對業務的態度，會因你在團隊中承擔的角色不同而不同。這是由開發團隊的組織結構和職責分工導致的。
下面是我繪制的“團隊結構、能力與職責”圖：
在一個開發團隊中，架構師這個角色，會負責業務拆分和軟件架構的工作，并且領導團隊來實現滿足業務的軟件。
注1 ：有的研發團隊里有業務架構師和軟件架構師兩種角色，業務拆分由業務架構師或業務分析師完成。
注2 ：軟件架構師和業務架構師這兩個角色也可能由沒有架構師頭銜的研發經理兼任。
架構師一定是要以業務為導向的，要搞懂業務的。所以，在架構師這個階段，在團隊管理者這個階段，業務的重要性，往往是高于技術的，在他們的眼中，業務統領技術，技術是用來實現業務的。
當團隊完成業務架構和軟件架構之后，就會選擇不同的開發者來負責不同功能模塊的實現。
負責不同功能模塊實現的開發者，必須能夠理解業務，并且要熟悉某個技術棧，能夠進行模塊設計和任務拆分，我稱這樣的開發者為“熟練開發者”。
熟練開發者會承接由架構師分派的子業務，負責模塊設計和拆分，把拆分后的小任務，交給普通程序員來完成。
當你是一個熟練開發者時，業務和技術幾乎同等重要，因為：
- 你不理解業務，就很難將子業務模塊映射到軟件實現上，也很難做進一步的業務拆分。
- 你不具備完整的技術棧和相應的知識體系，就很難找到合適的技術來實現業務，也很難做軟件模塊的拆分。
熟練開發者完成了子業務和軟件模塊的拆分，會形成一系列的葉子型任務，并把它們分派給具備特定專項技術能力的普通程序員。
普通程序員要做的事情比較簡單，就是接受別人分派的任務，實現特定的業務細節。
注意當你是一個普通程序員的時候，團隊要求你具備一定的專項技術能力，能夠完成任務即可，你的角色，就拿把螺絲刀擰螺絲，擰好螺絲就 Ok 。
這個時候，你內心是痛苦的，對不停地寫業務代碼是拒絕的，因為你要再找工作時，別的組織看重你的專項技術能力甚于業務能力（他們有人做業務拆分，你過去了能擰螺絲即可），而你在現有組織中，卻因為深陷業務代碼的編寫而無法持續淬煉你的技能能力。
所以普通程序員最糾結寫業務代碼這件事！
那么，該如何才能解脫呢？
5. 如何從寫業務代碼中跳出來
孔子說過一段話：“弟子入則孝，出則悌，謹而信，泛愛眾而親仁，行有余力，則以學文。”
翻譯成現代文，是這個意思：“年輕人，在家就要孝順父母，出門在外就要尊敬兄長，行為謹慎，言語有信，博愛眾人，親近仁者。這樣都做到之后還有余力的話，就可以去學習從政，做更大的事業。”
這段話呢，給普通程序員指明了方向：輕松搞定你的業務代碼，還有余力，就可以做更重要的事情。
也就是說，當下你能力不夠，組織上不可能給你更復雜的模塊讓你負責（再說團隊里已經有更厲害的人在做那些事了），你得先輕松且漂亮地搞定手上的任務再說。
很多普通程序員天天抱怨老寫業務代碼沒長進，可手上的任務卻總是敷衍了事，完成得湊湊合合，那是很難擺重復簡單業務任務的泥沼的。
那怎樣才能做到輕松、漂亮地搞定任務呢？ 4 點：
- 在深度和廣度兩個方面提升技術能力（如果當下任務繁重，就利用業余時間練習）
- 把自己的做的事情放在全局理解，提升業務理解能力
- 培養好的工作習慣，比如計劃、回顧等
- 做好匯報和展示，讓領導知道你的能力
當你慢慢做了上面 4 點之后，每次拿到任務，都能輕松又漂亮地搞定，超出領導的預期，還有未發揮完的火力，那團隊就一定會給你復雜一點的任務，如果你還能輕松、漂亮地搞定并且還有余力，那團隊就會給你復雜度再高一些的任務……
往復循環，你就可以跳出最簡單的業務代碼編寫，做越來越重要的事情，人也變得越來越重要。
6. 小結
前面我們分 5 個部分闡述了業務和技術的關系，總結一下，關鍵的其實有 3 點：
- 技術是手段，業務是目的；軟件開發工作是以業務為導向的，但是沒有技術又無法實現業務。
- 業務和技術的關系，隨著開發者角色的變化而變化。
- 剛入行時作為普通程序員，技術是基礎，有技術才能實現業務，公司在招人時也以技術水平為門檻，從這點出發，一定要在短期內迅速提升技術。
- 工作了 3 、 5 年，成了熟練開發者，可以獨自負責一個業務模塊時，需要更好地理解業務，這樣才能更好的從技術上實現，此時業務和技術并重。
- 從熟練開發者往前發展，有兩條路，技術專家和架構師，如果你選擇架構師的路線，則應該調整思維，以業務為導向，把業務放在更重要的位置，因為架構是從業務拆分出來的，如果你選擇技術專家路線，則需要在深耕技術的同時保持對業務的敏感。
- 普通程序員要想從業務代碼的泥沼中跳出，要從技術水平、做事的方法、習慣和自我展示幾方面入手，努力做到搞定任務有余力，進入正向循環，慢慢獲得做重要事情的機會，讓自己變得重要。
