從架構理解價值-個人軟件世界觀（轉載）

目錄

• 程序員的迷茫－找尋不到價值
• 業務、技術與軟件系統的價值鏈
• 價值驅動的架構
  • 什麼是架構
  • 成本與收益
  • 架構目標須要適應業務的發展
  • 成也分工，敗也分工
• 從價值出發－找尋學習與工做的新思路

程序員的迷茫－找尋不到價值

在浩大的軟件世界裏，做爲一名普通程序員，顯得十分眇小，甚至會感到迷茫。咱們心裏崇拜技術，卻也對突飛猛進的技術抱有深深的恐懼。技術市場就像這喜怒不定的老天爺，今天下個大數據雨，明天刮我的工智能風，面對琳琅滿目的技術浪潮的衝擊，程序員不免深感無力，深怕錯過了技術潮流從而失去了職場競爭力。有時候我會思考難道在技術領域內不斷緊跟新潮，不斷提高技能就是個人價值所在?那麼我是技術的主人仍是技術的奴隸？
人之因此迷茫每每是找不到工做生活的重心，感覺不到工做或生活的價值。那麼什麼是價值呢？說的大一點就是我改變了世界，說的小一點就是個人所做所爲改善了某些問題。若是不清楚本身的行爲、目標、價值三者的關係，那麼又何來重心？又如何能分得清重要性與優先級呢？
程序員的迷茫不只僅是面對技術繁雜的無力感，更重要的是由於長期埋沒於軟件世界的浩大的分工體系中，沒法看清從業務到軟件架構的價值鏈條，沒法清楚定位本身在分工體系的位置，處理很差自身與技術、業務的關係所致。
不少程序員打心底不喜歡業務，這一點我曾經也經歷過，我更寧願從事框架工具、技術組件研究的相關事情。我有個朋友常常吐槽我說:"大家每天加班加點寫了那麼多代碼，而後呢？有改變什麼嗎？還不是寫出了一堆垃圾。"仔細想一想不少時候業務在咱們腦海中存留的只是邏輯和流程，咱們丟失的是對業務場景的感覺，對用戶痛點的體會，對業務發展的思考。這些都是與價值緊密相關的部分。咱們很天然的用戰術的勤快掩蓋戰略的懶惰！那麼這樣的後果就是咱們把本身限死在流水線的工位上，閹割了本身可以發現業務價值的能力，而過多關注新技術對職場競爭力的價值。這也就是咱們面對繁雜技術，而產生技術學習焦慮症的根本緣由。

業務、技術與軟件系統的價值鏈

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

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

• 業務領域與功能：好比支付寶立足支付領域而推出的轉帳、收款功能等,好比人工智能自動駕駛系統等。
• 服務能力：這就比如火車站購票窗口，評判它的服務能力的標準就是它可以同時處理多少的用戶購票業務，能不能在指定時間內完成購票業務，能不能7*8小時持續工做。對應到軟件系統領域，則表現爲
  • 系統正確性(程序可以正確表述業務流程，沒有Bug)。
  • 可用性（能夠7＊24小時＊365不間歇工做）。
  • 大規模（高併發，高吞吐量）。

互聯網公司正是藉助大規模的軟件系統承載着繁多的業務功能，使其擁有巨大的服務能力並藉助互聯網技術突破了空間限制，高效低廉解決了業務問題，創造了豐厚的利潤，這是人肉所不可比擬的。
理解了這一層面的概念，你就能夠清楚這個價值鏈條即：公司依靠軟件系統提供業務服務而創造價值，程序員則是經過構建並持續演進軟件系統服務能力以及業務功能以支撐公司業務發展從而創造價值。
有了這個價值鏈條，咱們就能夠反思本身的工做學習對軟件系統的服務能力提高起到了多大的推進做用？能夠反思本身的工做學習是否切實在解決領域的業務問題，仍是隻是作一些意義不大的重複性工做。
前兩天面試了一個候選人，他的工做是從事票務系統開發，他說本身在研究linux內核與彙編語言，我就問他linux內核和彙編語言的學習對你的工做產生了哪些幫助？可否舉一個例子？他啞口無言，我心裏就以爲這樣一個熱愛學習的好苗子正迷茫找不到重心，正在作一件的浪費精力的事情。正確的學習方式應該是將學習與具體業務場景結合起來，和公司經過軟件系統開展業務服務而創造價值，程序員經過提高軟件系統服務能力創造價值這一鏈條串接起來，從對這些價值產生幫助的程度去思考優先級。學習自己沒有錯，錯的每每就是那顆初心
如今你再來看高併發分佈式相關的知識，你會發現並非由於這些知識比較高深、比較時髦，不少公司有需求才值得學習，而是他們對價值鏈條有着實實在在的貢獻。

價值驅動的架構

一談到軟件系統，人們免不了想起架構這件事來。之因此此處去談及架構是由於每個程序員本質都是軟件架構體系中的一分子，咱們可能深埋於體系流水線之中，感覺不到位置和價值。但若是站在架構這一高度去看這些問題則將會很是透徹。那麼架構到底是什麼？和上述的價值鏈又有什麼關係呢？

什麼是架構

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

• 組織業務：架構師經過探索和研究業務領域的知識，構建自身看待業務的"世界觀"。他會基於這種認識拆分業務生命週期，確立業務邊界，構建出了一套解決特定業務問題的領域模型。而且確認模型之間、領域之間的關係與協做方式。完成了對業務領域內的要素的組織工做。
• 組織技術：爲了能在計算機世界中運做人類社會的業務模型，架構師須要選用計算機世界中合適的框架、中間件、編程語言、網絡協議等技術工具依據以前設計方案組織起來造成一套軟件系統方案，在我看來軟件系統就像是一種技術組織，即技術組件、技術手段依據某種邏輯被組織起來了，這些技術工具被肯定了職責，有了明確分工，並以實現業務功能爲目標集合在了一塊兒。好比RPC框架或消息隊列被用於內部系統之間的通訊服務就如同信使通常，而數據庫則負責記錄結果，它更像是一名書記員。
• 組織人員：爲了可以實現利用軟件系統解決業務問題的目標，架構師還須要關注軟件系統的構建過程，他以實現軟件系統爲號召，從公司組織中彙集一批軟件工程師，並將這些人員按不一樣工種、不一樣職責、不一樣系統進行組織，肯定這些人員之間的協做方式，並關注這個組織系統是否運做良比如如溝通是否順暢、產出是否達到要求、可否按時間完成等。
• 組織全局，對外輸出：架構師的首要目標是解決業務問題，推進業務增加。因此他很是關心軟件的運行情況。由於只有在軟件系統運行起來後，才能對外提供服務，才能在用戶訪問的過程當中，解決業務問題。架構師須要關注運行過程當中產生的數據好比業務成功率，系統運行資源佔用數據、用戶反饋信息、業務增加狀況等，這些信息將會幫助架構師制定下一步架構目標和方向。

因此軟件架構不只僅只是選用什麼框架、選用什麼技術組件這麼簡單。它貫穿了對人的組織、對技術的組織、對業務的組織，並將這三種組織以解決業務問題這一目標有機的結合在了一塊兒。
不少面試的候選人在被問及他所開發的系統採用什麼架構的問題時，只會羅列出一些技術組件、技術框架等技術要素，這樣看來其根本沒有理清架構的深層含義。也有一些架構師只專一對底層技術的研究，覺得打造一個卓越的系統是很是牛逼的事情，但是他忽略了軟件系統的價值是以解決業務問題的能力、支撐業務增加的能力爲衡量標準，因此最後生產出了不少對組織，對業務沒有幫助的系統。

成本與收益

正如以前所說軟件系統只有在運行的時候才能創造價值，也就是說軟件系統可否7*24小時＊365天穩定的工做關係到公司的收益水平。因此開發團隊對生產環境的發佈老是當心翼翼，對解決生產環境的問題老是加班加點。而軟件系統的成本則體如今軟件構建過程，這時候咱們就能理解那些工程技術如項目管理、敏捷開發、單元測試、持續集成、持續構建，版本管理等的價值了，他們有的是保證軟件系統正確性，有的是爲了下降溝通成本，有的是爲了提高開發效率等但總的來講就是爲了下降軟件的構建成本。因此在提高系統服務能力，創造更多業務收益的同時，下降構建成本也是一種提高收益的有效手段。
做爲一名軟件工程師而言，咱們每每處在軟件構建過程體系中的某個環節，咱們能夠基於成本與收益的關係去思考本身每一項技能的價值，學習新的有價值的技能，甚至在工做中基於成本與收益的考量選擇合適的技術。好比在邏輯不大發生變化的地方，沒有必要去作過多的設計，應用各類花俏的設計模式等浪費時間。這樣咱們才能成爲技術的主人。

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

架構的目標就是爲了支撐業務增加，就是提高軟件系統的服務能力。但是話雖然說如此，但真實卻要作不少取捨。好比對初創團隊而言，其產品是否解決業務問題這一設想還沒獲得確認，就當即去構造一個高性能、高可用的分佈式系統，這樣的架構目標遠超出業務發展的需求，最後的結果就是浪費大量人力物力，卻得不到任何轉機。架構師須要審時度勢，仔細衡量正確性、大規模、可用性三者的關係，好比今年業務蓬勃發展日均訂單300萬，基於對將來的可能預測，明年可能有3000萬的訂單，那麼架構師應該要着重考慮大規模和可用性。並且每一點提高的程度，也須要架構師衡量把握，好比可用性要達到2個9仍是3個9。
回顧本身以往的工做不少時候就是由於沒有確立架構目標緻使浪費了組織不少資源，好比在以前的創業團隊中，因爲本人有必定的代碼潔癖，常常會花費不少時間和同事計較代碼質量，這樣本能夠更快上線的功能卻須要被延遲，當時過分追求正確性的行爲是與創業團隊快速驗證想法的業務需求不匹配的。另一點比較深入的案例則是在本人擔任一個技術團隊負責人的時候，在一次述職報告的時候，leader問我對接下來團隊工做有什麼計劃？我當時說了一堆什麼改進代碼質量，天天晨會，任務透明化，創建迭代機制等等，而後就被各類批駁一通。當時團隊基本之外包人員爲主，人員水平較差，開發出來的金融系統也是千瘡百孔而這條業務線最重要的業務價值則是按計劃實現潛在投資方的需求，爭取拉到投資。因此不久leader就召集測試架構的相關人員與我這邊一同梳理對核心功能的測試工做，將研發、測試、上線的流程自動化。當時並不理解這樣作核心價值是什麼？但回過頭來看這樣的工做方式剛好符合了業務發展的需求，即確保系統是符合設計需求的，保證系統達到可接受的正確性，爲後續能過快速前進打下基礎，最重要的是爲企業下降了構建成本。因此程序員想要工做出業績，必須認清楚系統背後的業務價值，按價值去梳理工做優先級，而不是像我通常過分糾結細節，追求技術理想化。

成也分工，敗也分工

正如在程序員的迷茫那一章節提到的：程序員的迷茫由於長期埋沒於軟件世界的浩大的分工體系中，沒法看清從業務到軟件架構的價值鏈條，沒法清楚定位本身在分工體系的位置，處理很差自身與技術、業務的關係所致，因此在這裏我想談談分工。架構師爲了使軟件系統更好的服務業務，必然將軟件系統生命週期進行拆分，好比分出開發生命週期、測試生命週期、用戶訪問生命週期、軟件運維生命週期。並根據不一樣的生命週期劃分出不一樣的職責與角色，好比開發人員負責開發週期負責完成軟件研發，測試人員負責對開發人員交付的成果進行測試等，因而就造成了分工。一旦分工造成，每個分工組織都會有本身的價值追求，架構師關注的頂層的價值即軟件系統可否支撐業務增加被分工的形式打碎到各個組織中。分工是有其價值的，他使得複雜昂貴的任務能夠被簡單、並行、可替換的流水線方式解決。但長此以往，價值碎片化的問題就出現了，好比測試人員只關注找出更多問題，開發人員只關注快速開發更多的系統，運維人員只關注保障系統穩定。三者之間經常都只站在本身的立場去要求對方怎麼作，沒有人再關注總體價值，產生諸多矛盾增長軟件實施成本。而身處流水線中的一員，又由於困擾於重複性工做，迷茫於工做的意義，甚至感受本身作爲了人的創意與靈感都被扼殺了。因此個人朋友吐槽我說你寫了那麼多代碼而後並無怎麼樣是很是有道理的，那是由於我只關注着作爲流水工人的價值要求，看不到生態鏈最頂端的價值。
咱們仔細想一想那些團隊領導，精英領袖哪個不是爲着更廣大的價值所負責，好比項目經理只須要關心自身項目的商業價值，而公司CEO則關心公司範疇內全部業務的整體商業價值。因此關注的價值越大且職位也就越高。這些高層領導者們把控着總體的價值鏈條，及時糾正底層分工組織的價值目標與總體價值目標出現誤差的問題。

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

迷茫能引起思考，架構則塑造了視野，而價值則是咱們之因此存活，之因此工做的邏輯起點。基於這樣一種價值思惟，對咱們的學習和工做又能夠有哪些改啓示呢？

• 明確自身的業務相關主體：找出你工做的協做關係網內的業務方和客戶方，這樣你就能夠從客戶方中找到離你最近的業務價值點，從你的業務方中挖掘更多的資源。甚至你能夠按這個思路順着網絡向上或向下挖掘價值鏈條，整合更多的上下游資源以實現更大的價值。
• 向前一步，爲更大的價值負責：不要由於本身是開發人員就不去關注軟件運維，不要由於只是測試就不關注軟件開發，由於你關注的越多你越能看清全局的價值目標。若是隻關注一畝三分地，那麼註定這輩子只能困守在這一畝三分地裏，成爲一名流水線上焦慮至死的碼農。試着轉變思惟，從架構師的角度思考價值問題，看看可否將技術貫穿到業務、到用戶、到最終的價值去。以前個人朋友說過要把產品經理踢到運營位置去，把程序員踢到產品經理位置去，這樣纔是正確作事方式。這句話也是相似的意思，向前一步才能懂得怎麼作的更好。
• 像架構師同樣思考，用價值找尋重心：人的迷茫是由於找不到重心，而價值的意義在於引導咱們思考作哪些事情才能實現價值，先作哪些事情會比後作哪些事情更能創造收益。像架構師那樣全局性思考，把遇到問題進行拆分，把學習到的事物串聯起來，努力構成完整的價值鏈條。
• 學會鏈接，構建體系：前幾天看到一篇文章對今日頭條的產品形態極盡批判之詞，指責它的智能算法將人類封死在本身的喜愛之中，將人類社會進一步碎片化。這彷佛頗有道理，有趣的是互聯網將咱們鏈接至廣袤的世界，卻也把咱們封閉在獨屬於本身的小世界裏。依舊是個人那位朋友，他說他的最大價值在於鏈接，將不一樣的人鏈接在一塊兒，有趣的事情可能就會即將發生。或許算法的天性就是順從與迎合，但人最終想理解這個世界仍是須要依靠自身的行動與不一樣人之間創建聯繫，這也是一種擺脫流水線限制的有效方式。另外，咱們自身也是某種事物鏈接的產物，好比架構師，他是業務、技術、管理鏈接在一塊兒的一種產物。因此咱們應當樹立自身的知識體系以吸取融合新知識，將孤立的概念鏈接起來，造成自身的價值鏈條。好比這篇文章將我從事技術開發經驗、與對架構的理解以及自身過往經歷結合起來，這也是一種內在的體系梳理。

做者：D調的暖冬
連接：https://www.jianshu.com/p/6ebf289d0e05