往事

2014年3月，Martin Fowler和James Lewis率先提出了微服務(wù)架構(gòu)這一武功秘籍，各路豪杰紛紛研習(xí)，一時(shí)大熱。然而不到一年，有人不得要領(lǐng)，有人走火入魔。Martin不得不再次出面，告誡人們要單體先行，切忌急功近利。不足七日，便有人在Martin的門戶中公然唱反調(diào)，指責(zé)單體先行萬不可取。后有曾為微服務(wù)秘籍做注的Sam Newman不置可否地說，只待時(shí)機(jī)成熟，方可修煉。一時(shí)間眾說紛紜，江湖大亂。有詩為證：

分析企架皆模式，代碼重構(gòu)精益精。

縱橫軟件四十載，江湖人稱老馬丁。

一朝創(chuàng)立微服務(wù)，卻勸君單體先行。

莫問風(fēng)雪何時(shí)了，你若歡喜便是晴。

新生

三體星上的和平愛好者對(duì)人類的忠告是：不要回答，不要回答，不要回答。

而人類面對(duì)軟件業(yè)諸多懸而未解的問題則是：無法回答，無法回答，無法回答。

時(shí)間永遠(yuǎn)不會(huì)因?yàn)槿祟愑薮赖募姞幎Ｖ顾哪_步，轉(zhuǎn)眼間坐標(biāo)來到了2019年。兩位分別來自英國和比利時(shí)的多才多藝的年輕人機(jī)緣巧合地聚在了一起。他們?cè)谇叭颂亓ⅹ?dú)行的思想基礎(chǔ)上，結(jié)合了認(rèn)知心理學(xué)，提出了一個(gè)頗為大膽的假設(shè)：單體還是微服務(wù)并不重要，重要的是團(tuán)隊(duì)的認(rèn)知負(fù)載。

初看這一理論似乎并無太多新意，但細(xì)品之后簡直如醍醐灌頂。Martin Fowler和Sam Newman們無法用語言表達(dá)出來的模棱兩可，被如此輕描淡寫地化解。就仿佛一個(gè)置身四維空間的神，在低頭嘲笑三維空間中渺小的人類。這是一個(gè)徹徹底底的降維打擊。

不僅微服務(wù)架構(gòu)如是，你甚至可以就此發(fā)散開去：

• 敏捷開發(fā)取代瀑布式開發(fā)是為哪般？?
• DevOps怎么會(huì)突然興起？?
• 云計(jì)算為何如此火熱？為什么我們現(xiàn)在構(gòu)建的軟件都最好是云原生的？?

你會(huì)發(fā)現(xiàn)，團(tuán)隊(duì)認(rèn)知負(fù)載理論，或者說整個(gè)團(tuán)隊(duì)拓?fù)鋵W(xué)，并不僅僅是一個(gè)方法論，而是一個(gè)全新的世界觀。

什么是認(rèn)知負(fù)載？

認(rèn)知負(fù)載理論由認(rèn)知心理學(xué)家John Sweller于1988年首次提出，它是指從事一件工作所要使用的腦力勞動(dòng)的總和。Sweller在研究Problem Solving的時(shí)候發(fā)現(xiàn)，不同的教學(xué)方式會(huì)對(duì)學(xué)習(xí)者產(chǎn)生不同的效果，造成不同效果的根本原因就是認(rèn)知負(fù)載。

信息要想存儲(chǔ)在長期記憶中，就必須先被工作記憶（working memory）關(guān)注并處理。然而工作記憶的容量和持續(xù)時(shí)間都十分有限。在某些情況下，這些限制會(huì)阻礙學(xué)習(xí)進(jìn)程，影響學(xué)習(xí)效果。沉重的認(rèn)知負(fù)載會(huì)對(duì)學(xué)習(xí)產(chǎn)生負(fù)面影響。

Sweller將認(rèn)知負(fù)載分為以下三類：

• 內(nèi)在（instrinsic）認(rèn)知負(fù)載，是指與特定主題相關(guān)的腦力勞動(dòng)。?
• 外在（extraneous）認(rèn)知負(fù)載，是指向?qū)W習(xí)者呈現(xiàn)信息或任務(wù)的方式。?
• 相關(guān)（germane）認(rèn)知負(fù)載，是指為創(chuàng)建永久的知識(shí)存儲(chǔ)而付出的努力。?

團(tuán)隊(duì)認(rèn)知負(fù)載與軟件開發(fā)

Matthew Skelton和Manuel Pais（剛才提到的那兩位“年輕人”）在他們提出的團(tuán)隊(duì)拓?fù)鋵W(xué)中，倡導(dǎo)團(tuán)隊(duì)優(yōu)先的思維方式，以降低團(tuán)隊(duì)認(rèn)知負(fù)載為宗旨，避免工作內(nèi)容（架構(gòu)、運(yùn)維等）超出團(tuán)隊(duì)的最大認(rèn)知負(fù)載。這樣，整個(gè)團(tuán)隊(duì)就可以處于一個(gè)非常舒服的狀態(tài)，去有效地應(yīng)對(duì)軟件的復(fù)雜性，而不是疲于奔命。這種“以人為本”的思考方式，遠(yuǎn)遠(yuǎn)優(yōu)于單體或微服務(wù)那種只關(guān)注技術(shù)本身的視角。

Matthew和Manuel不但把認(rèn)知負(fù)載的概念引入到了軟件開發(fā)領(lǐng)域，同時(shí)給出了他們對(duì)于不同分類的解讀。

• 內(nèi)在認(rèn)知負(fù)載是指開發(fā)所需要的知識(shí)，如Java知識(shí)、前端知識(shí)等，也就是技術(shù)。?
• 外在認(rèn)知負(fù)載是指如何部署、如何調(diào)試以及如何配置等，也就是機(jī)制。?
• 相關(guān)認(rèn)知負(fù)載是指軟件要解決的問題，也就是與業(yè)務(wù)、領(lǐng)域相關(guān)的知識(shí)。?

其中，內(nèi)在認(rèn)知負(fù)載是固定不變的，它是我們開發(fā)軟件所必備的知識(shí)；外在認(rèn)知負(fù)載是需要盡量減少的，盡量避免與開發(fā)本身無關(guān)的腦力勞動(dòng)；相關(guān)認(rèn)知負(fù)載是要盡可能最大化的，因?yàn)檫@是我們?cè)陂_發(fā)軟件時(shí)必須了解的業(yè)務(wù)知識(shí)。

為什么要盡可能減少外在認(rèn)知負(fù)載呢？比如一個(gè)線上bug，修復(fù)它的內(nèi)在認(rèn)知負(fù)載可能很低，只需要修改一行代碼。但我們?cè)谛迯?fù)之前，搭環(huán)境、準(zhǔn)備數(shù)據(jù)、調(diào)試、測試……可能一兩天的時(shí)間就這么過去了。這就是外在認(rèn)知負(fù)載過高（環(huán)境不好搭、數(shù)據(jù)不好準(zhǔn)備、不好調(diào)試、不好測試等）帶來的問題。

又比如每一個(gè)開發(fā)人員都遭受過的來自業(yè)務(wù)方或需求方的靈魂拷問：為什么這個(gè)需求這么簡單，卻要開發(fā)這么多天？其實(shí)需求看似簡單，但這里要改，那里要改，零零碎碎加起來就是需要好幾天。你可能也很委屈，但你是否想過哪里出了問題呢？為什么簡單的需求不能快速地上線？你也許會(huì)想到霰彈式修改，但這些都是表象。根本原因就是不合理的架構(gòu)和代碼結(jié)構(gòu)，增加了團(tuán)隊(duì)的外在認(rèn)知負(fù)載。

唯一的答案

回到最開始的那些問題，你是否有了答案？

人們?yōu)槭裁床辉敢馊ヅ鰟?dòng)輒幾百頁的需求文檔，而更愿意閱讀只有一兩頁的故事卡？因?yàn)橥庠谡J(rèn)知負(fù)載：以厚而全的文檔向人們呈現(xiàn)需求的方式，大大增加了外在認(rèn)知負(fù)載。

人們?yōu)槭裁床辉敢馊ス芾黹L長的維護(hù)清單，而更喜歡基礎(chǔ)設(shè)施即代碼？因?yàn)橥庠谡J(rèn)知負(fù)載：以代碼的形式來管理基礎(chǔ)設(shè)施，顯然要比手動(dòng)運(yùn)維具有更低的外在認(rèn)知負(fù)載。

人們?yōu)槭裁床辉敢庾约嚎刂栖浖膹椥?、韌性，而更希望將軟件部署到云上？因?yàn)橥庠谡J(rèn)知負(fù)載：把專業(yè)的事情交給專業(yè)的團(tuán)隊(duì)去做，開發(fā)人員只專注業(yè)務(wù)代碼，將與己無關(guān)的外在認(rèn)知負(fù)載拋在身后輕裝上陣。

從這個(gè)角度來看，單體微服務(wù)之爭是否顯得過于低級(jí)了呢？答案是如此顯而易見。你只需要評(píng)估一下什么樣的架構(gòu)更能減輕當(dāng)前團(tuán)隊(duì)的認(rèn)知負(fù)載（確切地說是外在認(rèn)知負(fù)載）就可以了。

軟件行業(yè)過往一切懸而未決的問題、似是而非的論斷，似乎都有了答案，唯一的答案。

是誰出的題這么的難？到處全都是正確答案。?