程式設計師的迷茫不僅僅是面對技術繁雜的無力感，更重要的是因為長期埋沒於軟體 世界的浩大的分工體系中，無法看清從業務到軟體架構的價值鏈條，無法清楚定位自 己在分工體系的位置，處理不好自身與技術、業務的關係所致。
很多程式設計師打心底不喜歡業務，這一點我曾經也經歷過，我更寧願從事框架工 具、技術元件研究的相關事情。我有個朋友經常吐槽我說：”你們天天加班加點寫了 那麼多程式碼，然後呢？有改變什麼嗎？還不是寫出了一堆垃圾。”仔細想想很多時候 業務在我們腦海中存留的只是邏輯和流程，我們丟失的是對業務場景的感受，對用 戶痛點的體會，對業務發展的思考。這些都是與價值緊密相關的部分。我們很自然的 用戰術的勤快掩蓋戰略的懶惰！那麼這樣的後果就是我們把自己限死在流水線的工位 上，閹割了自己能夠發現業務價值的能力，而過多關注新技術對職場競爭力的價值。 這也就是我們面對繁雜技術，而產生技術學習焦慮症的根本原因。
那麼什麼是業務呢？
就是指某種有目的的工作或工作專案，業務的目的就是解
決人類社會與吃喝住行息息相關的領域問題，包括物質的需求和精神的需求，使開展
業務活動的主體和受眾都能得到利益。通俗的講業務就是使用者的痛點，是業務提供方
（比如公司）的盈利點。而技術則是解決問題的工具和手段。比如為了解決使用者隨時隨
地購物的業務問題時，程式設計師利用 web 技術構建電子商務 App，而當需求升級為幫
助使用者快速選購商品時，程式設計師會利用資料演算法等技術手段構建推薦引擎。 技術如果
脫離了業務，那麼技術應用就無法很好的落地，技術的研究也將失去場景和方向。而
業務脫離了技術，那麼業務的開展就變得極其昂貴和低效。
所以回過頭來我們想想自己沒日沒夜寫了那麼多的程式碼從而構建起來的軟體系
統，它的價值何在呢？說白了就是為了解決業務問題，所以當你所從事的工作內容並
不能為解決業務問題帶來多大幫助的時候，你應該要及時做出調整。那麼軟體系統又
是如何體現它自身的價值呢？在我看來有如下幾個方面的體現：
業務領域與功能：比如支付寶立足支付領域而推出的轉賬、收款功能等，比如人 工智慧自動駕駛系統等。
服務能力：這就好比火車站購票視窗，評判它的服務能力的標準就是它能夠同時 處理多少使用者的購票業務，能不能在指定時間內完成購票業務，能不能 7*8 小時持續 工作。對應到軟體系統領域，則表現為以下三個方面：
- 系統正確性 ( 程式能夠正確表述業務流程，沒有 Bug)
- 可用性（可以 7 ＊ 24 小時＊ 365 不間歇工作）
- 大規模（高併發，高吞吐量）
網際網路公司正是藉助大規模的軟體系統承載著繁多的業務功能，使其擁有巨大的 服務能力並藉助網際網路技術突破了空間限制，高效低廉解決了業務問題，創造了豐厚 的利潤，這是人肉所不可比擬的。
理解了這一層面的概念，你就可以清楚這個價值鏈條：公司依靠軟體系統提供業 務服務而創造價值，程式設計師則是通過構建並持續演進軟體系統服務能力以及業務功能 以支撐公司業務發展從而創造價值。
有了這個價值鏈條，我們就可以反思自己的工作學習對軟體系統的服務能力提升 起到了多大的推動作用？可以反思自己的工作學習是否切實在解決領域的業務問題， 還是隻是做一些意義不大的重複性工作。
什麼是架構？
在我看來軟體架構就是將人員、技術等資源組織起來以解決業務問題，支撐業務 增長的一種活動。可能比較抽象，我想我們可以從架構師的一些具體工作任務來理解 這句話含義：
組織業務：架構師通過探索和研究業務領域的知識，構建自身看待業務的”世界 觀”。他會基於這種認識拆分業務生命週期，確立業務邊界，構建出了一套解決特定 業務問題的領域模型，並且確認模型之間、領域之間的關係與協作方式，完成了對業 務領域內的要素的組織工作。
組織技術：為了能在計算機世界中運作人類社會的業務模型，架構師需要選用計 算機世界中合適的框架、中介軟體、程式語言、網路協議等技術工具依據之前設計方 案組織起來形成一套軟體系統方案，在我看來軟體系統就像是一種技術組織，即技 術元件、技術手段依據某種邏輯被組織起來了，這些技術工具被確定了職責，有了明 確分工，並以實現業務功能為目標集合在了一起。比如 RPC 框架或訊息佇列被用 於內部系統之間的通訊服務就如同信使一般，而資料庫則負責記錄結果，它更像是 一名書記員。
組織人員：為了能夠實現利用軟體系統解決業務問題的目標，架構師還需要關注 軟體系統的構建過程，他以實現軟體系統為號召，從公司組織中聚集一批軟體工程 師，並將這些人員按不同工種、不同職責、不同系統進行組織，確定這些人員之間的 協作方式，並關注這個組織系統是否運作良好比如溝通是否順暢、產出是否達到要 求、能否按時間完成等。
組織全域性，對外輸出：架構師的首要目標是解決業務問題，推動業務增長。所以
他非常關心軟體的執行狀況。因為只有在軟體系統執行起來後，才能對外提供服務，
才能在使用者訪問的過程中，解決業務問題。架構師需要關注執行過程中產生的資料比
如業務成功率，系統執行資源佔用資料、使用者反饋資訊、業務增長情況等，這些資訊
將會幫助架構師制定下一步架構目標和方向。
所以軟體架構不僅僅只是選用什麼框架、選用什麼技術元件這麼簡單。它貫穿了
對人的組織、對技術的組織、對業務的組織，並將這三種組織以解決業務問題這一目
標有機的結合在了一起。
很多面試的候選人在被問及他所開發的系統採用什麼架構的問題時，只會羅列出
一些技術元件、技術框架等技術要素，這樣看來其根本沒有理清架構的深層含義。也
有一些架構師只專注對底層技術的研究，以為打造一個卓越的系統是非常牛逼的事
情，可是他忽略了軟體系統的價值是以解決業務問題的能力、支撐業務增長的能力為
衡量標準，所以最後生產出了很多對組織，對業務沒有幫助的系統。
成本與收益
正如之前所說軟體系統只有在執行的時候才能創造價值，也就是說軟體系統能否 7*24 小時＊ 365 天穩定的工作關係到公司的收益水平。所以開發團隊對生產環境的 釋出總是小心翼翼，對解決生產環境的問題總是加班加點。而軟體系統的成本則體現 在軟體構建過程，這時候我們就能理解那些工程技術如專案管理、敏捷開發、 單元測 試、持續整合、持續構建，版本管理等的價值了，他們有的是保證軟體系統正確性， 有的是為了降低溝通成本，有的是為了提升開發效率等但總的來說就是為了降低軟體 的構建成本。所以在提升系統服務能力，創造更多業務收益的同時，降低構建成本也 是一種提升收益的有效手段。
作為一名軟體工程師而言，我們往往處在軟體構建過程體系中的某個環節，我們 可以基於成本與收益的關係去思考自己每一項技能的價值，學習新的有價值的技能， 甚至在工作中基於成本與收益的考量選擇合適的技術。比如在邏輯不大發生變化的地 方，沒有必要去做過多的設計，應用各種花俏的設計模式等浪費時間。這樣我們才能 成為技術的主人。
架構目標需要適應業務的發展
架構的目標就是為了支撐業務增長，就是提升軟體系統的服務能力。可是話雖說
如此，但真實卻要做很多取捨。比如對初創團隊而言，其產品是否解決業務問題這一
設想還沒得到確認，就立即去構造一個高效能、高可用的分散式系統，這樣的架構目
標遠超出業務發展的需求，最後的結果就是浪費大量人力物力，卻得不到任何起色。
架構師需要審時度勢，仔細衡量正確性、大規模、可用性三者的關係，比如今年業務
蓬勃發展日均訂單 300 萬，基於對未來的可能預測，明年可能有 3000 萬的訂單，那
麼架構師應該要著重考慮大規模和可用性。而且每一點提升的程度，也需要架構師衡
量把握，比如可用性要達到 2 個 9 還是 3 個 9。
回顧自己以往的工作很多時候就是因為沒有確立架構目標導致浪費了組織很多資
源，比如在之前的創業團隊中，由於本人有一定的程式碼潔癖，經常會花費很多時間和
同事計較程式碼質量，這樣本可以更快上線的功能卻需要被延遲，當時過度追求正確性
的行為是與創業團隊快速驗證想法的業務需求不匹配的。
從價值出發－找尋學習與工作的新思路
向前一步，為更大的價值負責：不要因為自己是開發人員就不去關注軟體運維，
不要因為只是測試就不關注軟體開發，因為你關注的越多你越能看清全域性的價值目
標。如果只關注一畝三分地，那麼註定這輩子只能困守在這一畝三分地裡，成為一名
流水線上焦慮至死的碼農。試著轉變思維，從架構師的角度思考價值問題，看看能否
將技術貫穿到業務、到使用者、到最終的價值去。之前我的朋友說過要把產品經理踢到
運營位置去，把程式設計師踢到產品經理位置去，這樣才是正確做事方式。這句話也是類
似的意思，向前一步才能懂得怎麼做的更好。
像架構師一樣思考，用價值找尋重心：人的迷茫是因為找不到重心，而價值的意
義在於引導我們思考做哪些事情才能實現價值，先做哪些事情會比後做哪些事情更能
創造收益。像架構師那樣全域性性思考，把遇到問題進行拆分，把學習到的事物串聯起
來，努力構成完整的價值鏈條。