在我眼里，也經常會把程序員分成兩類：一種是我等這種寫業務代碼的程序員，另外一種是研究高深算法、造“輪子”的“科學家”...
將他們稱之為科學家是有些夸張，第一次冒出這樣的想法是參加一個技術大會，當別的嘉賓都在分享開發、設計、架構、管理方面的經驗時，一名在騰訊工作的算法工程師（應該已經是一個小領導了），他上臺分享了一些諸如：滑動平均自回歸模型、神經網絡基因表達式編程、SVM回歸機集成學習...坐在臺下的我第一次冒出這樣的念頭：“這**是科學家研究的東西吧。”
當然，倒也不能說寫業務代碼就很low，寫業務代碼也不是想象中那么簡單的。
寫業務相關的代碼，必須了解業務流程，還需要了解業務人員心里是怎么想的，也就是業務出發點是什么樣子的。
比如我最近遇到一個需求，過程大概是這樣的：銷售人員在賣一款產品，這款產品非常火，有些優秀的銷售人員一周可能能賣出去幾百上千單；結果我們接到一個需求，要限制每個代理人的銷售數量，比如每人只能賣10個（之前已經賣掉的不算）；這就讓我們非常奇怪，本來賣的好好的，為什么要做這個限制呢？這個需求看起來就非常的不合理。
后來業務人員和我們解釋了一下原因：因為這款產品公司不掙錢，銷售人員為了推這個產品，花在別的產品上的時間就少了，所以出這個功能，就是讓銷售人員“收收心”，把精力放在其他產品上。
這么一解釋，我們就立刻明白了；所以如果你不明白業務的時候，看著需求敲代碼也是非常容易出錯的。
有些人會認為業務邏輯就是一堆if-else，但是我認為在實際工作中，這些if-else也是非常難做到的。
業務邏輯是人設計的，業務邏輯難不可怕，可怕的是它不嚴謹和變化快；業務邏輯和那些確定性的東西不一樣，比如我們寫好的代碼if-else兩個分支，那么再怎么也不會跳出這個范圍，業務邏輯就不一樣了，它是非常靈活的、不確定的，業務機會來的快消失的也快，我們很難開發出來一套全面的、完善的、靈活的的系統，去應對將來可能會發生的需求。
所以在開發過程中，如果可以將業務流程拆分成多個組件模型，組件和組件配合完成一個完成的業務流程；當業務發生變化或有新業務的時候，只需要重新編排這些組件，或對某一個組件做少量更改，就可以滿足業務變化；如果能做到這個程度，也是非常不容易的。
在這個過程中，你需要做到高內聚低耦合，避免過度抽象，從業務流程和動機出發，已滿足業務需要為主；既然做不了“科學家”，我們就努力把業務代碼寫好把。