往事
2014年3月，Martin Fowler和James Lewis率先提出了微服務(wù)架構(gòu)這一武功秘籍，各路豪杰紛紛研習(xí)，一時(shí)大熱。然而不到一年，有人不得要領(lǐng)，有人走火入魔。Martin不得不再次出面，告誡人們要單體先行，切忌急功近利。不足七日，便有人在Martin的門(mén)戶中公然唱反調(diào)，指責(zé)單體先行萬(wàn)不可取。后有曾為微服務(wù)秘籍做注的Sam Newman不置可否地說(shuō)，只待時(shí)機(jī)成熟，方可修煉。一時(shí)間眾說(shuō)紛紜，江湖大亂。有詩(shī)為證：
分析企架皆模式，代碼重構(gòu)精益精。
縱橫軟件四十載，江湖人稱老馬丁。
一朝創(chuàng)立微服務(wù)，卻勸君單體先行。
莫問(wèn)風(fēng)雪何時(shí)了，你若歡喜便是晴。
新生
三體星上的和平愛(ài)好者對(duì)人類的忠告是：不要回答，不要回答，不要回答。
而人類面對(duì)軟件業(yè)諸多懸而未解的問(wèn)題則是：無(wú)法回答，無(wú)法回答，無(wú)法回答。
時(shí)間永遠(yuǎn)不會(huì)因?yàn)槿祟愑薮赖募姞?zhēng)而停止她的腳步，轉(zhuǎn)眼間坐標(biāo)來(lái)到了2019年。兩位分別來(lái)自英國(guó)和比利時(shí)的多才多藝的年輕人機(jī)緣巧合地聚在了一起。他們?cè)谇叭颂亓ⅹ?dú)行的思想基礎(chǔ)上，結(jié)合了認(rèn)知心理學(xué)，提出了一個(gè)頗為大膽的假設(shè)：?jiǎn)误w還是微服務(wù)并不重要，重要的是團(tuán)隊(duì)的認(rèn)知負(fù)載。
初看這一理論似乎并無(wú)太多新意，但細(xì)品之后簡(jiǎn)直如醍醐灌頂。Martin Fowler和Sam Newman們無(wú)法用語(yǔ)言表達(dá)出來(lái)的模棱兩可，被如此輕描淡寫(xiě)地化解。就仿佛一個(gè)置身四維空間的神，在低頭嘲笑三維空間中渺小的人類。這是一個(gè)徹徹底底的降維打擊。
不僅微服務(wù)架構(gòu)如是，你甚至可以就此發(fā)散開(kāi)去：
- 敏捷開(kāi)發(fā)取代瀑布式開(kāi)發(fā)是為哪般？?
- DevOps怎么會(huì)突然興起？?
- 云計(jì)算為何如此火熱？為什么我們現(xiàn)在構(gòu)建的軟件都最好是云原生的？?
你會(huì)發(fā)現(xiàn)，團(tuán)隊(duì)認(rèn)知負(fù)載理論，或者說(shuō)整個(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ǔ)在長(zhǎng)期記憶中，就必須先被工作記憶（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ù)載與軟件開(kāi)發(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ù)載的概念引入到了軟件開(kāi)發(fā)領(lǐng)域，同時(shí)給出了他們對(duì)于不同分類的解讀。
- 內(nèi)在認(rèn)知負(fù)載是指開(kāi)發(fā)所需要的知識(shí)，如Java知識(shí)、前端知識(shí)等，也就是技術(shù)。?
- 外在認(rèn)知負(fù)載是指如何部署、如何調(diào)試以及如何配置等，也就是機(jī)制。?
- 相關(guān)認(rèn)知負(fù)載是指軟件要解決的問(wèn)題，也就是與業(yè)務(wù)、領(lǐng)域相關(guān)的知識(shí)。?
其中，內(nèi)在認(rèn)知負(fù)載是固定不變的，它是我們開(kāi)發(fā)軟件所必備的知識(shí)；外在認(rèn)知負(fù)載是需要盡量減少的，盡量避免與開(kāi)發(fā)本身無(wú)關(guān)的腦力勞動(dòng)；相關(guān)認(rèn)知負(fù)載是要盡可能最大化的，因?yàn)檫@是我們?cè)陂_(kāi)發(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)試、測(cè)試……可能一兩天的時(shí)間就這么過(guò)去了。這就是外在認(rèn)知負(fù)載過(guò)高（環(huán)境不好搭、數(shù)據(jù)不好準(zhǔn)備、不好調(diào)試、不好測(cè)試等）帶來(lái)的問(wèn)題。
又比如每一個(gè)開(kāi)發(fā)人員都遭受過(guò)的來(lái)自業(yè)務(wù)方或需求方的靈魂拷問(wèn)：為什么這個(gè)需求這么簡(jiǎn)單，卻要開(kāi)發(fā)這么多天？其實(shí)需求看似簡(jiǎn)單，但這里要改，那里要改，零零碎碎加起來(lái)就是需要好幾天。你可能也很委屈，但你是否想過(guò)哪里出了問(wèn)題呢？為什么簡(jiǎn)單的需求不能快速地上線？你也許會(huì)想到霰彈式修改，但這些都是表象。根本原因就是不合理的架構(gòu)和代碼結(jié)構(gòu)，增加了團(tuán)隊(duì)的外在認(rèn)知負(fù)載。
唯一的答案
回到最開(kāi)始的那些問(wèn)題，你是否有了答案？
人們?yōu)槭裁床辉敢馊ヅ鰟?dòng)輒幾百頁(yè)的需求文檔，而更愿意閱讀只有一兩頁(yè)的故事卡？因?yàn)橥庠谡J(rèn)知負(fù)載：以厚而全的文檔向人們呈現(xiàn)需求的方式，大大增加了外在認(rèn)知負(fù)載。
人們?yōu)槭裁床辉敢馊ス芾黹L(zhǎng)長(zhǎng)的維護(hù)清單，而更喜歡基礎(chǔ)設(shè)施即代碼？因?yàn)橥庠谡J(rèn)知負(fù)載：以代碼的形式來(lái)管理基礎(chǔ)設(shè)施，顯然要比手動(dòng)運(yùn)維具有更低的外在認(rèn)知負(fù)載。
人們?yōu)槭裁床辉敢庾约嚎刂栖浖膹椥?、韌性，而更希望將軟件部署到云上？因?yàn)橥庠谡J(rèn)知負(fù)載：把專業(yè)的事情交給專業(yè)的團(tuán)隊(duì)去做，開(kāi)發(fā)人員只專注業(yè)務(wù)代碼，將與己無(wú)關(guān)的外在認(rèn)知負(fù)載拋在身后輕裝上陣。
從這個(gè)角度來(lái)看，單體微服務(wù)之爭(zhēng)是否顯得過(guò)于低級(jí)了呢？答案是如此顯而易見(jiàn)。你只需要評(píng)估一下什么樣的架構(gòu)更能減輕當(dāng)前團(tuán)隊(duì)的認(rèn)知負(fù)載（確切地說(shuō)是外在認(rèn)知負(fù)載）就可以了。
軟件行業(yè)過(guò)往一切懸而未決的問(wèn)題、似是而非的論斷，似乎都有了答案，唯一的答案。
是誰(shuí)出的題這么的難？到處全都是正確答案。?
