很多程序員打心底不喜歡業務，這一點我曾經也經歷過，我更寧願從事框架工 具、技術組件研究的相關事情。我有個朋友經常吐槽我說：”你們天天加班加點寫了 那麽多代碼，然後呢？有改變什麽嗎？還不是寫出了一堆垃圾。”仔細想想很多時候 業務在我們腦海中存留的只是邏輯和流程，我們丟失的是對業務場景的感受，對用 戶痛點的體會，對業務發展的思考。這些都是與價值緊密相關的部分。我們很自然的 用戰術的勤快掩蓋戰略的懶惰！那麽這樣的後果就是我們把自己限死在流水線的工位 上，閹割了自己能夠發現業務價值的能力，而過多關註新技術對職場競爭力的價值。 這也就是我們面對繁雜技術，而產生技術學習焦慮癥的根本原因。

那麽什麽是業務呢？
就是指某種有目的的工作或工作項目，業務的目的就是解 決人類社會與吃喝住行息息相關的領域問題，包括物質的需求和精神的需求，使開展 業務活動的主體和受眾都能得到利益。通俗的講業務就是用戶的痛點，是業務提供方 （比如公司）的盈利點。而技術則是解決問題的工具和手段。比如為了解決用戶隨時隨 地購物的業務問題時，程序員利用 web 技術構建電子商務 App，而當需求升級為幫 助用戶快速選購商品時，程序員會利用數據算法等技術手段構建推薦引擎。 技術如果 脫離了業務，那麽技術應用就無法很好的落地，技術的研究也將失去場景和方向。而 業務脫離了技術，那麽業務的開展就變得極其昂貴和低效。

所以回過頭來我們想想自己沒日沒夜寫了那麽多的代碼從而構建起來的軟件系 統，它的價值何在呢？說白了就是為了解決業務問題，所以當你所從事的工作內容並 不能為解決業務問題帶來多大幫助的時候，你應該要及時做出調整。那麽軟件系統又 是如何體現它自身的價值呢？在我看來有如下幾個方面的體現：

業務領域與功能：比如支付寶立足支付領域而推出的轉賬、收款功能等，比如人 工智能自動駕駛系統等。

服務能力：這就好比火車站購票窗口，評判它的服務能力的標準就是它能夠同時 處理多少用戶的購票業務，能不能在指定時間內完成購票業務，能不能 7*8 小時持續 工作。對應到軟件系統領域，則表現為以下三個方面：

系統正確性 ( 程序能夠正確表述業務流程，沒有 Bug)

可用性（可以 7 ＊ 24 小時＊ 365 不間歇工作）

大規模（高並發，高吞吐量）

互聯網公司正是借助大規模的軟件系統承載著繁多的業務功能，使其擁有巨大的 服務能力並借助互聯網技術突破了空間限制，高效低廉解決了業務問題，創造了豐厚 的利潤，這是人肉所不可比擬的。

理解了這一層面的概念，你就可以清楚這個價值鏈條：公司依靠軟件系統提供業 務服務而創造價值，程序員則是通過構建並持續演進軟件系統服務能力以及業務功能 以支撐公司業務發展從而創造價值。

有了這個價值鏈條，我們就可以反思自己的工作學習對軟件系統的服務能力提升 起到了多大的推動作用？可以反思自己的工作學習是否切實在解決領域的業務問題， 還是只是做一些意義不大的重復性工作。

什麽是架構？
在我看來軟件架構就是將人員、技術等資源組織起來以解決業務問題，支撐業務 增長的一種活動。可能比較抽象，我想我們可以從架構師的一些具體工作任務來理解 這句話含義：

組織業務：架構師通過探索和研究業務領域的知識，構建自身看待業務的”世界 觀”。他會基於這種認識拆分業務生命周期，確立業務邊界，構建出了一套解決特定 業務問題的領域模型，並且確認模型之間、領域之間的關系與協作方式，完成了對業 務領域內的要素的組織工作。

組織技術：為了能在計算機世界中運作人類社會的業務模型，架構師需要選用計 算機世界中合適的框架、中間件、編程語言、網絡協議等技術工具依據之前設計方 案組織起來形成一套軟件系統方案，在我看來軟件系統就像是一種技術組織，即技 術組件、技術手段依據某種邏輯被組織起來了，這些技術工具被確定了職責，有了明 確分工，並以實現業務功能為目標集合在了一起。比如 RPC 框架或消息隊列被用 於內部系統之間的通信服務就如同信使一般，而數據庫則負責記錄結果，它更像是 一名書記員。

組織人員：為了能夠實現利用軟件系統解決業務問題的目標，架構師還需要關註 軟件系統的構建過程，他以實現軟件系統為號召，從公司組織中聚集一批軟件工程 師，並將這些人員按不同工種、不同職責、不同系統進行組織，確定這些人員之間的 協作方式，並關註這個組織系統是否運作良好比如溝通是否順暢、產出是否達到要 求、能否按時間完成等。

組織全局，對外輸出：架構師的首要目標是解決業務問題，推動業務增長。所以 他非常關心軟件的運行狀況。因為只有在軟件系統運行起來後，才能對外提供服務， 才能在用戶訪問的過程中，解決業務問題。架構師需要關註運行過程中產生的數據比 如業務成功率，系統運行資源占用數據、用戶反饋信息、業務增長情況等，這些信息 將會幫助架構師制定下一步架構目標和方向。

所以軟件架構不僅僅只是選用什麽框架、選用什麽技術組件這麽簡單。它貫穿了 對人的組織、對技術的組織、對業務的組織，並將這三種組織以解決業務問題這一目 標有機的結合在了一起。

很多面試的候選人在被問及他所開發的系統采用什麽架構的問題時，只會羅列出 一些技術組件、技術框架等技術要素，這樣看來其根本沒有理清架構的深層含義。也 有一些架構師只專註對底層技術的研究，以為打造一個卓越的系統是非常牛逼的事 情，可是他忽略了軟件系統的價值是以解決業務問題的能力、支撐業務增長的能力為 衡量標準，所以最後生產出了很多對組織，對業務沒有幫助的系統。

成本與收益
正如之前所說軟件系統只有在運行的時候才能創造價值，也就是說軟件系統能否 7*24 小時＊ 365 天穩定的工作關系到公司的收益水平。所以開發團隊對生產環境的 發布總是小心翼翼，對解決生產環境的問題總是加班加點。而軟件系統的成本則體現 在軟件構建過程，這時候我們就能理解那些工程技術如項目管理、敏捷開發、 單元測 試、持續集成、持續構建，版本管理等的價值了，他們有的是保證軟件系統正確性， 有的是為了降低溝通成本，有的是為了提升開發效率等但總的來說就是為了降低軟件 的構建成本。所以在提升系統服務能力，創造更多業務收益的同時，降低構建成本也 是一種提升收益的有效手段。

作為一名軟件工程師而言，我們往往處在軟件構建過程體系中的某個環節，我們 可以基於成本與收益的關系去思考自己每一項技能的價值，學習新的有價值的技能， 甚至在工作中基於成本與收益的考量選擇合適的技術。比如在邏輯不大發生變化的地 方，沒有必要去做過多的設計，應用各種花俏的設計模式等浪費時間。這樣我們才能 成為技術的主人。

架構目標需要適應業務的發展
架構的目標就是為了支撐業務增長，就是提升軟件系統的服務能力。可是話雖說 如此，但真實卻要做很多取舍。比如對初創團隊而言，其產品是否解決業務問題這一 設想還沒得到確認，就立即去構造一個高性能、高可用的分布式系統，這樣的架構目 標遠超出業務發展的需求，最後的結果就是浪費大量人力物力，卻得不到任何起色。 架構師需要審時度勢，仔細衡量正確性、大規模、可用性三者的關系，比如今年業務 蓬勃發展日均訂單 300 萬，基於對未來的可能預測，明年可能有 3000 萬的訂單，那 麽架構師應該要著重考慮大規模和可用性。而且每一點提升的程度，也需要架構師衡 量把握，比如可用性要達到 2 個 9 還是 3 個 9。

回顧自己以往的工作很多時候就是因為沒有確立架構目標導致浪費了組織很多資 源，比如在之前的創業團隊中，由於本人有一定的代碼潔癖，經常會花費很多時間和 同事計較代碼質量，這樣本可以更快上線的功能卻需要被延遲，當時過度追求正確性 的行為是與創業團隊快速驗證想法的業務需求不匹配的。

從價值出發－找尋學習與工作的新思路
向前一步，為更大的價值負責：不要因為自己是開發人員就不去關註軟件運維， 不要因為只是測試就不關註軟件開發，因為你關註的越多你越能看清全局的價值目 標。如果只關註一畝三分地，那麽註定這輩子只能困守在這一畝三分地裏，成為一名 流水線上焦慮至死的碼農。試著轉變思維，從架構師的角度思考價值問題，看看能否 將技術貫穿到業務、到用戶、到最終的價值去。之前我的朋友說過要把產品經理踢到 運營位置去，把程序員踢到產品經理位置去，這樣才是正確做事方式。這句話也是類 似的意思，向前一步才能懂得怎麽做的更好。

像架構師一樣思考，用價值找尋重心：人的迷茫是因為找不到重心，而價值的意 義在於引導我們思考做哪些事情才能實現價值，先做哪些事情會比後做哪些事情更能 創造收益。像架構師那樣全局性思考，把遇到問題進行拆分，把學習到的事物串聯起 來，努力構成完整的價值鏈條。

喜歡小編輕輕點個關註哦！

一個思維習慣，讓你成為架構師