一個思惟習慣，讓你成爲架構師

  程序員的迷茫不只僅是面對技術繁雜的無力感，更重要的是由於長期埋沒於軟件 世界的浩大的分工體系中，沒法看清從業務到軟件架構的價值鏈條，沒法清楚定位自 己在分工體系的位置，處理很差自身與技術、業務的關係所致。

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

那麼什麼是業務呢？

  就是指某種有目的的工做或工做項目，業務的目的就是解 決人類社會與吃喝住行息息相關的領域問題，包括物質的需求和精神的需求，使開展 業務活動的主體和受衆都能獲得利益。通俗的講業務就是用戶的痛點，是業務提供方 （好比公司）的盈利點。而技術則是解決問題的工具和手段。好比爲了解決用戶隨時隨 地購物的業務問題時，程序員利用 web 技術構建電子商務 App，而當需求升級爲幫 助用戶快速選購商品時，程序員會利用數據算法等技術手段構建推薦引擎。 技術若是 脫離了業務，那麼技術應用就沒法很好的落地，技術的研究也將失去場景和方向。而 業務脫離了技術，那麼業務的開展就變得極其昂貴和低效。
  因此回過頭來咱們想一想本身沒日沒夜寫了那麼多的代碼從而構建起來的軟件系 統，它的價值何在呢？說白了就是爲了解決業務問題，因此當你所從事的工做內容並 不能爲解決業務問題帶來多大幫助的時候，你應該要及時作出調整。那麼軟件系統又 是如何體現它自身的價值呢？在我看來有以下幾個方面的體現：

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

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

• 系統正確性 ( 程序可以正確表述業務流程，沒有 Bug)
• 可用性（能夠 7 ＊ 24 小時＊ 365 不間歇工做）
• 大規模（高併發，高吞吐量）

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

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

  有了這個價值鏈條，咱們就能夠反思本身的工做學習對軟件系統的服務能力提高 起到了多大的推進做用？能夠反思本身的工做學習是否切實在解決領域的業務問題， 仍是隻是作一些意義不大的重複性工做。

什麼是架構？

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

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

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

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

  組織全局，對外輸出：架構師的首要目標是解決業務問題，推進業務增加。因此 他很是關心軟件的運行情況。由於只有在軟件系統運行起來後，才能對外提供服務， 才能在用戶訪問的過程當中，解決業務問題。架構師須要關注運行過程當中產生的數據比 如業務成功率，系統運行資源佔用數據、用戶反饋信息、業務增加狀況等，這些信息 將會幫助架構師制定下一步架構目標和方向。
  因此軟件架構不只僅只是選用什麼框架、選用什麼技術組件這麼簡單。它貫穿了 對人的組織、對技術的組織、對業務的組織，並將這三種組織以解決業務問題這一目 標有機的結合在了一塊兒。
  不少面試的候選人在被問及他所開發的系統採用什麼架構的問題時，只會羅列出 一些技術組件、技術框架等技術要素，這樣看來其根本沒有理清架構的深層含義。也 有一些架構師只專一對底層技術的研究，覺得打造一個卓越的系統是很是牛逼的事 情，但是他忽略了軟件系統的價值是以解決業務問題的能力、支撐業務增加的能力爲 衡量標準，因此最後生產出了不少對組織，對業務沒有幫助的系統。

成本與收益

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

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

架構目標須要適應業務的發展

  架構的目標就是爲了支撐業務增加，就是提高軟件系統的服務能力。但是話雖然說 如此，但真實卻要作不少取捨。好比對初創團隊而言，其產品是否解決業務問題這一 設想還沒獲得確認，就當即去構造一個高性能、高可用的分佈式系統，這樣的架構目 標遠超出業務發展的需求，最後的結果就是浪費大量人力物力，卻得不到任何轉機。 架構師須要審時度勢，仔細衡量正確性、大規模、可用性三者的關係，好比今年業務 蓬勃發展日均訂單 300 萬，基於對將來的可能預測，明年可能有 3000 萬的訂單，那 麼架構師應該要着重考慮大規模和可用性。並且每一點提高的程度，也須要架構師衡 量把握，好比可用性要達到 2 個 9 仍是 3 個 9。
  回顧本身以往的工做不少時候就是由於沒有確立架構目標緻使浪費了組織不少資 源，好比在以前的創業團隊中，因爲本人有必定的代碼潔癖，常常會花費不少時間和 同事計較代碼質量，這樣本能夠更快上線的功能卻須要被延遲，當時過分追求正確性 的行爲是與創業團隊快速驗證想法的業務需求不匹配的。

從價值出發－找尋學習與工做的新思路

  向前一步，爲更大的價值負責：不要由於本身是開發人員就不去關注軟件運維， 不要由於只是測試就不關注軟件開發，由於你關注的越多你越能看清全局的價值目 標。若是隻關注一畝三分地，那麼註定這輩子只能困守在這一畝三分地裏，成爲一名 流水線上焦慮至死的碼農。試着轉變思惟，從架構師的角度思考價值問題，看看可否 將技術貫穿到業務、到用戶、到最終的價值去。以前個人朋友說過要把產品經理踢到 運營位置去，把程序員踢到產品經理位置去，這樣纔是正確作事方式。這句話也是類 似的意思，向前一步才能懂得怎麼作的更好。
  像架構師同樣思考，用價值找尋重心：人的迷茫是由於找不到重心，而價值的意 義在於引導咱們思考作哪些事情才能實現價值，先作哪些事情會比後作哪些事情更能 創造收益。像架構師那樣全局性思考，把遇到問題進行拆分，把學習到的事物串聯起 來，努力構成完整的價值鏈條。

 結尾處驗證一下知識變現