[[209583]]

寫了這么多年的代碼，你是否曾經有過這樣的迷茫和困惑——技術發展日新月異，奮力追趕的我們，究竟是技術的主人還是技術的奴隸?螞蟻金服的技術專家空融，與大家一起來聊聊技術人的軟件世界觀。

[[209584]]

在浩大的軟件世界里，作為一名普通程序員，顯得十分渺小，甚至會感到迷茫。我們內心崇拜技術，卻也對日新月異的技術抱有深深的恐懼。

有時候我會思考難道在技術領域內不斷緊跟新潮，不斷提升技能就是我的價值所在?那么我是技術的主人還是技術的奴隸?

人之所以迷茫往往是找不到工作生活的重心，感受不到工作或生活的價值。那么什么是價值呢?

說的大一點就是我改變了世界，說的小一點就是我的所作所為改善了某些問題。

如果不清楚自己的行為、目標、價值三者的關系，那么又何來重心?又如何能分得清重要性與優先級呢?

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

很多程序員打心底不喜歡業務，這一點我曾經也經歷過，我更寧愿從事框架工具、技術組件研究的相關事情。

我有個朋友經常吐槽我說："你們天天加班加點寫了那么多代碼，然后呢?有改變什么嗎?還不是寫出了一堆垃圾。"

仔細想想很多時候業務在我們腦海中存留的只是邏輯和流程，我們丟失的是對業務場景的感受，對用戶痛點的體會，對業務發展的思考。這些都是與價值緊密相關的部分。

我們很自然的用戰術的勤快掩蓋了戰略的懶惰!這樣的后果就是我們把自己限死在流水線的工位上，閹割了自己能夠發現業務價值的能力，而過多關注新技術對職場競爭力的價值。

這也就是我們面對繁雜技術，而產生技術學習焦慮癥的根本原因。

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

什么是業務呢?就是指某種有目的的工作或工作項目，業務的目的就是解決人類社會與吃喝住行息息相關的領域問題，包括物質的需求和精神的需求，使開展業務活動的主體和受眾都能得到利益。

通俗的講業務就是用戶的痛點，是業務提供方(比如公司)的盈利點。而技術則是解決問題的工具和手段。

比如為了解決用戶隨時隨地購物的業務問題時，程序員利用 Web 技術構建電子商務 APP，而當需求升級為幫助用戶快速選購商品時，程序員會利用數據算法等技術手段構建推薦引擎。

技術如果脫離了業務，那么技術應用就無法很好的落地，技術的研究也將失去場景和方向。而業務脫離了技術，那么業務的開展就變得極其昂貴和低效。

[[209585]]

所以回過頭來我們想想自己沒日沒夜寫了那么多的代碼從而構建起來的軟件系統，它的價值何在呢?

說白了就是為了解決業務問題，所以當你所從事的工作內容并不能為解決業務問題帶來多大幫助的時候，你應該要及時做出調整。那么軟件系統又是如何體現它自身的價值呢?

在我看來有如下幾個方面的體現：

• 業務領域與功能：比如支付寶立足支付領域而推出的轉賬、收款功能等，比如采用人工智能的自動駕駛系統等。
• 服務能力：這就好比火車站購票窗口，評判它的服務能力的標準就是它能夠同時處理多少用戶的購票業務，能不能在指定時間內完成購票業務，能不能 7*8 小時持續工作。

對應到軟件系統領域，則表現為以下三個方面：

• 系統正確性：程序能夠正確表述業務流程，沒有 Bug。
• 可用性：可以 7*24 小時*365 不間歇工作。
• 大規模：高并發，高吞吐量。

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

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

有了這個價值鏈條，我們就可以反思自己的工作學習對軟件系統的服務能力提升起到了多大的推動作用?

可以反思自己的工作學習是否切實在解決領域的業務問題，還是只是做一些意義不大的重復性工作。

前兩天面試了一個候選人，他的工作是從事票務系統開發，他說自己在研究 Linux 內核與匯編語言，我就問他 Linux 內核和匯編語言的學習對你的工作產生了哪些幫助?能否舉一個例子?

他啞口無言，我內心就覺得這樣一個熱愛學習的好苗子正迷茫找不到重心，正在做一件浪費精力的事情。

正確的學習方式應該是將學習與具體業務場景結合起來，幫助公司通過軟件系統開展業務服務而創造價值。

程序員通過提升軟件系統服務能力創造價值這一鏈條串接起來，從對這些價值產生幫助的程度去思考優先級。學習本身沒有錯，錯的往往就是那顆初心。

現在你再來看高并發分布式相關的知識，你會發現并不是因為這些知識比較高深、比較時髦，很多公司有需求才值得學習，而是他們對價值鏈條有著實實在在的貢獻。

價值驅動的架構

一談到軟件系統，人們免不了想起架構這件事來。之所以此處去談及架構是因為每一個程序員本質都是軟件架構體系中的一分子，我們可能深埋于體系流水線之中，感受不到位置和價值。

但如果站在架構這一高度去看這些問題則將會非常透徹。那么架構究竟是什么?和上述的價值鏈又有什么關系呢?

什么是架構?

在我看來軟件架構就是將人員、技術等資源組織起來以解決業務問題，支撐業務增長的一種活動。

可能比較抽象，我想我們可以從架構師的一些具體工作任務來理解這句話的含義：

組織業務

架構師通過探索和研究業務領域的知識，構建自身看待業務的"世界觀"。

他會基于這種認識拆分業務生命周期，確立業務邊界，構建出來一套解決特定業務問題的領域模型，并且確認模型之間、領域之間的關系與協作方式，完成對業務領域內的要素的組織工作。

組織技術

為了能在計算機世界中運作人類社會的業務模型，架構師需要選用計算機世界中合適的框架、中間件、編程語言、網絡協議等技術工具依據之前設計方案組織起來形成一套軟件系統方案。

在我看來軟件系統就像是一種技術組織，即技術組件、技術手段依據某種邏輯被組織起來了，這些技術工具被確定了職責，有了明確分工，并以實現業務功能為目標集合在了一起。

比如 RPC 框架或消息隊列被用于內部系統之間的通信服務就如同信使一般，而數據庫則負責記錄結果，它更像是一名書記員。

[[209586]]

組織人員

為了能夠實現利用軟件系統解決業務問題的目標，架構師還需要關注軟件系統的構建過程。

他以實現軟件系統為號召，從公司組織中聚集一批軟件工程師，并將這些人員按不同工種、不同職責、不同系統進行組織，確定這些人員之間的協作方式，并關注這個組織系統是否運作良好比如溝通是否順暢、產出是否達到要求、能否按時間完成等。

組織全局，對外輸出

架構師的首要目標是解決業務問題，推動業務增長。所以他非常關心軟件的運行狀況。因為只有在軟件系統運行起來后，才能對外提供服務，才能在用戶訪問的過程中，解決業務問題。

架構師需要關注運行過程中產生的數據比如業務成功率，系統運行資源占用數據、用戶反饋信息、業務增長情況等，這些信息將會幫助架構師制定下一步架構目標和方向。

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

很多面試的候選人在被問及他所開發的系統采用什么架構的問題時，只會羅列出一些技術組件、技術框架等技術要素，這樣看來其根本沒有理清架構的深層含義。

也有一些架構師只專注對底層技術的研究，以為打造一個卓越的系統是非常牛逼的事情，可是他忽略了軟件系統的價值是以解決業務問題的能力、支撐業務增長的能力為衡量標準，所以***生產出了很多對組織，對業務沒有幫助的系統。

成本與收益

[[209587]]

正如之前所說軟件系統只有在運行的時候才能創造價值，也就是說軟件系統能否 7*24 小時*365 天穩定的工作關系到公司的收益水平。

所以開發團隊對生產環境的發布總是小心翼翼，對解決生產環境的問題總是加班加點。

而軟件系統的成本則體現在軟件構建過程，這時候我們就能理解那些工程技術如項目管理、敏捷開發、單元測試、持續集成、持續構建，版本管理等的價值了。

他們有的是保證軟件系統正確性，有的是為了降低溝通成本，有的是為了提升開發效率等但總的來說就是為了降低軟件的構建成本。

所以在提升系統服務能力，創造更多業務收益的同時，降低構建成本也是一種提升收益的有效手段。

作為一名軟件工程師而言，我們往往處在軟件構建過程體系中的某個環節，我們可以基于成本與收益的關系去思考自己每一項技能的價值，學習新的有價值的技能，甚至在工作中基于成本與收益的考量選擇合適的技術。

比如在邏輯不大發生變化的地方，沒有必要去做過多的設計，應用各種花俏的設計模式等浪費時間。這樣我們才能成為技術的主人。

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

架構的目標就是為了支撐業務增長，就是提升軟件系統的服務能力。可是話雖說如此，但真實卻要做很多取舍。

比如對初創團隊而言，其產品是否解決業務問題這一設想還沒得到確認，就立即去構造一個高性能、高可用的分布式系統，這樣的架構目標遠超出業務發展的需求，***的結果就是浪費大量人力物力，卻得不到任何起色。

架構師需要審時度勢，仔細衡量正確性、大規模、可用性三者的關系，比如今年業務蓬勃發展日均訂單 300 萬，基于對未來的可能預測，明年可能有 3000 萬的訂單，那么架構師應該要著重考慮大規模和可用性。

而且每一點提升的程度，也需要架構師衡量把握，比如可用性要達到 2 個 9 還是 3 個 9。

回顧自己以往的工作很多時候就是因為沒有確立架構目標導致浪費了組織很多資源。

比如在之前的創業團隊中，由于本人有一定的代碼潔癖，經常會花費很多時間和同事計較代碼質量，這樣本可以更快上線的功能卻需要被延遲，當時過度追求正確性的行為是與創業團隊快速驗證想法的業務需求不匹配的。

另外一點比較深刻的案例則是在本人擔任一個技術團隊負責人的時候，在一次述職報告的時候，leader 問我對接下來團隊工作有什么計劃?

我當時說了一堆什么改進代碼質量，每天晨會，任務透明化，建立迭代機制等等，然后就被各種批駁一通。

當時團隊基本以外包人員為主，人員水平較差，開發出來的金融系統也是千瘡百孔而這條業務線最重要的業務價值則是按計劃實現潛在投資方的需求，爭取拉到投資。

所以不久 leader 就召集測試架構的相關人員與我這邊一同梳理對核心功能的測試工作，將研發、測試、上線的流程自動化。當時并不理解這樣做的核心價值是什么。

但回過頭來看這樣的工作方式恰好符合了業務發展的需求，即確保系統是符合設計需求的，保證系統達到可接受的正確性，為后續能過快速前進打下基礎，最重要的是為企業降低了構建成本。

所以程序員想要工作出業績，必須認清楚系統背后的業務價值，按價值去梳理工作優先級，而不是像我一般過度糾結細節，追求技術理想化。

成也分工，敗也分工

正如在程序員的迷茫那一章節提到的：程序員的迷茫因為長期埋沒于軟件世界的浩大的分工體系中，無法看清從業務到軟件架構的價值鏈條，無法清楚定位自己在分工體系的位置，處理不好自身與技術、業務的關系所致，所以在這里我想談談分工。

架構師為了使軟件系統更好的服務業務，必然將軟件系統生命周期進行拆分。比如分出開發生命周期、測試生命周期、用戶訪問生命周期、軟件運維生命周期，并根據不同的生命周期劃分出不同的職責與角色。

[[209588]]

比如開發人員負責開發周期負責完成軟件研發，測試人員負責對開發人員交付的成果進行測試等，于是就形成了分工。

一旦分工形成，每一個分工組織都會有自己的價值追求，架構師關注的頂層的價值即軟件系統能否支撐業務增長被分工的形式打碎到各個組織中。

分工是有其價值的，他使得復雜昂貴的任務可以被簡單、并行、可替換的流水線方式解決。

但久而久之，價值碎片化的問題就出現了，比如測試人員只關注找出更多問題，開發人員只關注快速開發更多的系統，運維人員只關注保障系統穩定。

三者之間常常都只站在自己的立場去要求對方怎么做，沒有人在關注整體價值，產生諸多矛盾增加軟件實施成本。

而身處流水線中的一員，又因為困擾于重復性工作，迷茫于工作的意義，甚至感覺自己做為了人的創意與靈感都被扼殺了。

所以我的朋友吐槽我說你寫了那么多代碼然后并沒有怎么樣是非常有道理的，那是因為我只關注著做為流水工人的價值要求，看不到生態鏈最頂端的價值。

我們仔細想想那些團隊領導，精英***哪一個不是為著更廣大的價值所負責，比如項目經理只需要關心自身項目的商業價值，而公司 CEO 則關心公司范疇內所有業務的總體商業價值。

所以關注的價值越大且職位也就越高，這些高層***們把控著整體的價值鏈條，及時糾正底層分工組織的價值目標與整體價值目標出現偏差的問題。

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

迷茫能引發思考，架構則塑造了視野，而價值則是我們之所以存活，之所以工作的邏輯起點。基于這樣一種價值思維，對我們的學習和工作又可以有哪些改進啟示呢?

明確自身的業務相關主體

找出你工作的協作關系網內的業務方和客戶方，這樣你就可以從客戶方中找到離你最近的業務價值點，從你的業務方中挖掘更多的資源。

甚至你可以按這個思路順著網絡向上或向下挖掘價值鏈條，整合更多的上下游資源以實現更大的價值。

向前一步，為更大的價值負責

不要因為自己是開發人員就不去關注軟件運維，不要因為只是測試就不關注軟件開發，因為你關注的越多你越能看清全局的價值目標。

如果只關注一畝三分地，那么注定這輩子只能困守在這一畝三分地里，成為一名流水線上焦慮至死的碼農。

試著轉變思維，從架構師的角度思考價值問題，看看能否將技術貫穿到業務、到用戶、到最終的價值去。

之前我的朋友說過要把產品經理踢到運營位置去，把程序員踢到產品經理位置去，這樣才是正確的做事方式。這句話也是類似的意思，向前一步才能懂得怎么做的更好。

[[209589]]

像架構師一樣思考，用價值找尋重心

人的迷茫是因為找不到重心，而價值的意義在于引導我們思考做哪些事情才能實現價值，先做哪些事情會比后做哪些事情更能創造收益。

像架構師那樣全局性思考，把遇到的問題進行拆分，把學習到的事物串聯起來，努力構成完整的價值鏈條。

學會連接，構建體系

前幾天看到一篇文章對今日頭條的產品形態極盡批判之詞，指責它的智能算法將人類封死在自己的喜好之中，將人類社會進一步碎片化。

這似乎很有道理，有趣的是互聯網將我們連接至廣袤的世界，卻也把我們封閉在獨屬于自己的小世界里。

依舊是我的那位朋友，他說他的***價值在于連接，將不同的人連接在一起，有趣的事情可能就會即將發生。

或許算法的天性就是順從與迎合，但人最終想理解這個世界還是需要依靠自身的行動與不同人之間建立聯系，這也是一種擺脫流水線限制的有效方式。

另外，我們自身也是某種事物連接的產物，比如架構師，他是業務、技術、管理連接在一起的一種產物。

所以我們應當樹立自身的知識體系以吸收融合新知識，將孤立的概念連接起來，形成自身的價值鏈條。

比如這篇文章將我從事技術開發經驗、與對架構的理解以及自身過往經歷結合起來，這也是一種內在的體系梳理。