這里是Z哥的個人公眾號

每周五11：45 按時送達

當然了，也會時不時加個餐～

我的第「165」篇原創敬上

大家好，我是Z哥。

相信每一位真正的程序員心里都有這樣一個念想：只要我的技術夠牛，就能驅動業務的發展。

但是往往我們在不自覺間做的是背道而馳的事情。

業務：我希望在這個報表里多展示某個字段行不行？現在每次我都得手動把數據合并一下，有點麻煩。

技術：這個字段不在我們的系統里，要加上的話，我們需要從別的業務系統拿數據，比較麻煩，而且可能準確性和及時性都會差一些。如果非要加的話，開發工期會比較久，你需要走需求流程。

業務：啊，不是吧。多個字段顯示，有這么難嗎？

業務：用戶反饋這個活動鏈接分享給他的好友后他們點開是空白的。

技術：這個活動本身是站內活動，我們沒考慮會分享到站外的情況，所以這里信息校驗沒通過，導致頁面數據沒有返回給客戶端，造成了打開空白的情況。

業務：其實我只想知道……現在要怎么解決？

上面的這些景象是不是很熟悉呢？

那么技術驅動業務到底是不是存在呢？答案是肯定的。Z哥我認為，主要體現在以下兩個目標：

解決過去無法解決的問題

讓解決問題的效率大大提升

但是我們仔細來思考一下這兩個目標。

首先，「解決過去無法解決問題」。“過去無法解決”這六個字就已經勸退99%的人了，這里面一部分人的想法是：過去無法解決，現在肯定也沒法解決，算了。另一部分人甚至完全看不到這里存在問題，因為潛意識已經默認這個問題本就是現實的一部分。

其次，「讓解決問題的效率大大提升」。這幾乎肯定不是小打小鬧能實現的，必然要從一個新的思路來解決問題才有可能。然而，人的思維慣性會阻礙新思路的產生，很少有人可以跳脫出現有解決方案的框架來重新考慮問題。

所以真正能做到技術驅動業務的關鍵并不在于你的技術有多牛，而是思維能否跳脫出過去的束縛，并且要擁有業務感覺，要懂業務。因為從概念上來說，業務是“釘子”，技術是“錘子”，前者是問題，后者是問題的解決方案。

其實，先不要說能「驅動業務」，能做好「支撐業務」的人我覺得就是一位優秀的程序員了，因為要達到這點也不容易。具體可以從以下三個方面入手。

/01? 理解業務/

如果你無法吃透業務，真正理解業務，那么別說驅動業務了，你能把業務實現到預期的80%都不錯了，就像上面提到的第二段對話。

當然技術人員對業務的理解方式和業務方、產品經理并不完全相同。最大的區別在于，技術人員需要對業務的“不可見”部分了解更多。比如，多個環節背后的流轉過程，這會影響你的技術實現和程序設計。

對于這個方面，Z哥只給你一個建議，不管你用什么方式方法來理解業務，你一定要帶著：這個業務的提出是為了解決什么問題或者實現什么目的？

要做到這點有難度，因為大家的本位意識會讓你習慣于盯著開發工期、deadline這種方面。但是只要你能帶著這個角度去思考，至少可以將業務實現地無限接近預期的100%。

不過，理解業務最多算是一個目標校準的工作，而且還沒涉及到技術。我們要做好「支持業務」甚至是「驅動業務」的動力源還是在技術方面。

/02? 穩健、可擴展的基礎架構/

能夠支撐或者驅動業務的首要前提，必須是你的“地基”不但穩固而且要領先于業務去規劃。所以底層的基礎架構設計非常重要，如果視野僅僅關注“這個需求該怎么實現”自然達不到這樣的效果。

這一點需要提升你的軟件設計意識。簡單的像設計模式之類的，復雜一些的則需要你吃透一些經典的設計原則和設計思想背后的優缺點和適用場景。

常見的設計原則：

• SRP 單一職責

• OCP 開閉原則

• LSP 里氏替換原則

• DIP 依賴倒置原則

• ISP 接口隔離原則

這些設計原則都有標準的定義，我就不一一列出來了，不清楚的可以自行網上搜索。

常見的設計思想：

• 分層架構

• 六邊形架構

• 洋蔥架構

• 領域驅動設計

這里的每一個設計思想，都夠寫好幾篇文章，我這里就不展開了。

/03? 構建完備的領域模型/

上面的四個設計思想，要我說哪個最有用，肯定是DDD。最近幾年DDD也被炒的非常火。

這里的領域模型就是DDD中的概念。

我算是國內比較早一批接觸DDD并運用的人，大概在2014年的時候機緣巧合了解到了DDD，然后啃了兩本最經典的書，當時給我一種看到世外桃源的感覺（真實感受，不夸張）。

它讓代碼里的model變得有血有肉，好像你在設計一個虛擬城市一樣。這里需要擺一個物件，那么它需要長成什么樣子，你要盡可能詳細的描繪出來；那里需要擺一個人物，那么他長什么樣子，當時正在做什么事，也得描繪出來。

DDD讓你摒棄了傳統三層架構以數據表為核心的代碼設計方式，可以讓業務含義更多地體現在代碼中。如此的好處很明顯，就是你的代碼可擴展性必然很強，因為你的一個model體現了現實世界中所代表的對象，現實中的對象多了一種行為，那么給這個model增加一個對應的function就好。

如果你是一位DDD（領域驅動設計）新手，并對DDD感興趣，可以翻閱我2016年寫DDD系列文章《如何一步一步用DDD設計一個電商網站》來入門。（當時還沒開通公眾號，所以你得到我的博客去看：zacharyfan.com）

不過里面有些內容在后來我有新的理解，但并沒有更新。不過這不影響你體會DDD的優雅，所以你還是可以看看。

當你做好了前面的3步， 你就具備了驅動業務的前提條件。

懂業務。

基礎架構夠穩、彈性夠強。

現實的問題在技術維度上體現的夠清楚。

在這之上你就可以嘗試基于對領域模型的觀察找到前面提到的技術能夠驅動業務的兩個目標：

當前無法解決的問題

當前解決效率不高地方

好了總結一下。

這篇呢，Z哥和你分享了我對技術驅動業務這件事的看法。

我認為技術驅動業務的關鍵并不在于技術多好，而在打破慣性思維和對業務的理解深度上。

所以，如果你想真正做到驅動業務，不妨先將以下3點基礎工作做好，否則只是空想而已。

理解業務

穩健、可擴展的基礎架構

構建完備的領域模型

希望對你有所啟發。

推薦閱讀：

• 好的自我介紹，面試成功一大半
  

• 軟件如何優雅地向前兼容？
  

原創不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創作 ：）

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的心想技术驱动业务，却在背道而驰的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。