當(dāng)從單體應(yīng)用轉(zhuǎn)向“微”的一切——微服務(wù)、微前端，我們會發(fā)現(xiàn)還有很多“東西”要研發(fā)和維護(hù)。這就引出了一個問題：該由誰來負(fù)責(zé)呢？

舉個簡單的例子，設(shè)想一支由 6 名開發(fā)者組成的小型團(tuán)隊。

這支團(tuán)隊已經(jīng)創(chuàng)建并支持一款移動應(yīng)用、一項(xiàng) Alexa 技能、三款獨(dú)立的網(wǎng)絡(luò)應(yīng)用和十五個微服務(wù)。

盡管他們成功地在整個生態(tài)系統(tǒng)中實(shí)現(xiàn)了一定的標(biāo)準(zhǔn)化，但鑒于現(xiàn)代軟件開發(fā)的本質(zhì)，它只是很多而已。Python、Django、DynamoDB、S3、React、TypeScript、Tailwind、Swift 等等都一起工作，都是為了實(shí)現(xiàn)用戶界面、API、數(shù)據(jù)持久性、集成等等。

但對于任何一位開發(fā)者而言，這都太多了。

另外，每次 Sprint 都會有不同的改進(jìn)和修復(fù)需求，而且工作很少能夠在代碼庫中平均分配。一次 Sprint 可能要求對移動應(yīng)用程序進(jìn)行大量的改動，而接下來的 Sprint 可能要求主要在后端工作。

那么，問題來了：怎樣才能最好地部署一支團(tuán)隊，以適應(yīng)一次接一次 Sprint 的業(yè)務(wù)需求？換言之，我們怎樣才能更好進(jìn)行職責(zé)分配？

比如說，我們鼓勵專業(yè)化嗎？像指派 Emily 處理所有的移動開發(fā)工作，讓 Joe 負(fù)責(zé)網(wǎng)絡(luò)組件這樣的。除了技術(shù)棧之外，如果我們有十幾個微服務(wù)，我們會不會在它們周圍劃分界限，例如 Javier 負(fù)責(zé)微服務(wù) A 和 B，Anna 負(fù)責(zé)微服務(wù) C 和 D，諸如此類？如果他們特定領(lǐng)域的工作在連續(xù)數(shù)次 Sprint 都很輕松后會怎樣呢？能讓他們有一點(diǎn)空閑的時間嗎？

還是說，我們應(yīng)該努力優(yōu)化利用率，鼓勵更多的全棧、跨域文化，每個開發(fā)者都做這一切……這合理嗎？

影響因素

正如開發(fā)軟件一樣，我們在進(jìn)入一個解決方案之前，應(yīng)該退一步，試圖弄清楚我們要解決的問題。我認(rèn)為，在考慮開發(fā)者的職責(zé)和所有權(quán)時，應(yīng)該考慮以下四個方面：

1. 顯而易見的是生產(chǎn)力。當(dāng)所有條件都一樣時，我們要把團(tuán)隊的結(jié)構(gòu)安排得盡可能好，這樣才能讓他們完成的工作最大化。所以，優(yōu)化生產(chǎn)力往往是為了讓開發(fā)者的工作能夠與自己的技術(shù)和經(jīng)驗(yàn)保持一定的一致性。比如，Emily 在前一次 Sprint 中從事移動應(yīng)用的開發(fā)，那么她將會比那些一直在后端工作的開發(fā)者更早地開發(fā)出新的特性。
2. 我們也要重視質(zhì)量問題。和上面類似，在某個特定的代碼庫中擁有更多實(shí)踐經(jīng)驗(yàn)的開發(fā)者，可能會以更高的質(zhì)量來實(shí)現(xiàn)新的特性，而不是那些只在某次 Sprint 空降到團(tuán)隊，卻不了解結(jié)構(gòu)、模式或慣例的人。即使是最優(yōu)秀的開發(fā)者，在不了解代碼庫的情況下，也會寫出蹩腳的代碼。
3. 組織往往也需要降低開發(fā)者離職的風(fēng)險，以及隨之而去的知識。這才是問題的關(guān)鍵所在，而這往往與上述目標(biāo)相悖。盡管將一個又一個 Sprint 開發(fā)任務(wù)指派給一個移動開發(fā)者可以將生產(chǎn)力和質(zhì)量最大化，但是一旦這名開發(fā)者接到 Meta 招聘者的短信時，那么組織就會處于危險的境地。
4. 最后，我們不能忽視開發(fā)者的幸福感這個看不見的因素。不過，這件事也是非常復(fù)雜的。有些人喜歡多元化和新鮮感，所以當(dāng)他們在一次又一次 Sprint 被困于同一個系統(tǒng)時，就可能會降低生產(chǎn)力或者跳槽。另一些人則更愿意看到可預(yù)見的未來，并以擁有自己的領(lǐng)地為榮，頻繁跳槽會讓他們抓狂。換句話說，我們每個人都是不同的，但確保我們能夠得到滿足、有挑戰(zhàn)的機(jī)會，這一點(diǎn)很重要。

假設(shè)這些是需要考慮的正確因素，那么關(guān)鍵在于，每一家組織都要根據(jù)這些要素的“權(quán)重”來確定策略。優(yōu)化最重要的是什么？可能有些是時間緊迫帶來了壓力（如最后期限），因此生產(chǎn)力必須得到優(yōu)化。又或者，開發(fā)者市場是如此火爆，最重要的就是讓開發(fā)者感到開心，而不是什么提高生產(chǎn)力。也就是說，它在很大程度上取決于環(huán)境。

本文將在此探討“如何”做，并假定組織已經(jīng)了解自己將進(jìn)行優(yōu)化的內(nèi)容，并為團(tuán)隊建立職責(zé)而選擇一些模式。但是有哪些模式可選呢？下面是我遇到過的一些常見模式。

所有權(quán)模式

我們經(jīng)常會在代碼所有權(quán)的策略上做文章。有時候很默契：每個人都尊重這樣的安排：Joe 負(fù)責(zé)網(wǎng)絡(luò)的事情，Emily 負(fù)責(zé)移動開發(fā)，我負(fù)責(zé)支付微服務(wù)等等。其他時候，這也是正式的安排：管理層聘請 Joe 為網(wǎng)絡(luò)開發(fā)者，Emily 為移動開發(fā)者等。無論哪種情況，實(shí)踐中都是類似的：當(dāng)新的特性或修復(fù)問題出現(xiàn)時，我們會根據(jù)“擁有”的東西進(jìn)行劃分。

這讓我們（從個體角度來說）最大限度提高了生產(chǎn)力，并且（通常）提高了質(zhì)量。但是，它也存在一定的缺陷。

首先，人們可以儲存不同系統(tǒng)的第一手知識，如果有人“中了彩票”或“被公交車撞了”，企業(yè)就會面臨巨大的風(fēng)險。此外，如果開發(fā)者想要學(xué)習(xí)新事物，“所有權(quán)”有時就像一種束縛。

最后，必須指出的是，盡管個人生產(chǎn)力得到了提升（因?yàn)殚_發(fā)者很熟悉他們的代碼庫），但集體的生產(chǎn)力往往會隨著所有權(quán)的增加而下降。正如上面所討論的，由于工作負(fù)荷在每次 Sprint 并不能做到完全平衡，因此可能會造成擁有所有權(quán)的開發(fā)者出現(xiàn)“盛宴”和“饑荒”的情況。例如，在一次 Sprint 中，他們代碼庫中的工作超出了所有者能夠處理的范圍，這導(dǎo)致了很大的瓶頸（或加班到深夜?。搅讼聜€月就沒有什么事情可做了，而這個所有者或多或少就是閑著的。

自由競爭模式

當(dāng)組織感受到所有權(quán)帶來的種種痛楚時，他們傾向于放棄任何策略，只是隨心所欲：即自由競爭。這個模式就像它聽起來一樣的簡單。一位經(jīng)理看到那里有一堆工作，就說：“嘿，你，碼農(nóng)，趕緊干活吧！” 然后就這樣了。

盡管這樣的策略的確可以保證總體分配均衡（即 Emily 在沒有移動工作的時候也不會無所事事，因?yàn)樗焕ヌ幚?Python 服務(wù)），但這種模式可能既累人，又充滿質(zhì)量問題。如果我們沒有與我們所從事的代碼庫建立長久聯(lián)系，那么我們的工作就只是權(quán)宜之計，并以無知為指導(dǎo)。我們在短期內(nèi)采用了一種古怪的修復(fù)方法，因?yàn)椴恢栏玫霓k法，或者我們并不關(guān)心——下一次 Sprint 我們就會在不同的代碼庫里了！正如他們所說，“誰也不會把租來的汽車洗干凈?！?/span>

這種自由競爭的模式往往是由管理層推動的，他們理想化地認(rèn)為我們是可替換的勤雜工（也就是傳說中的全棧開發(fā)者），無論什么層級、系統(tǒng)或業(yè)務(wù)領(lǐng)域，都能夠迅速、優(yōu)雅而輕松地解決任何技術(shù)挑戰(zhàn)。當(dāng)然，這是無稽之談。除了最微不足道的系統(tǒng)或者最出色的開發(fā)者，其他的都太復(fù)雜了，如果沒有足夠的時間來提高我們的能力，就不可能掌握所有的東西。

管理權(quán)模式

現(xiàn)在，在所有權(quán)和自由競爭這兩個極端之間，存在著一種管理模式（或稱監(jiān)護(hù)權(quán)）。類似于所有權(quán)，開發(fā)者會在自己最擅長的領(lǐng)域管理特定的代碼庫，他們可能在這個項(xiàng)目中做了大部分的初始工作，他們的名字在代碼中隨處可見，但是他們并不是什么都要做。然而，必須在做出變更時，至少要征求他們的看法，讓他們參與到生產(chǎn)問題的分類或者是討論設(shè)計的變更。

比如，Emily 可以在門戶網(wǎng)站工作量繁重的時候過去幫 Joe 一把，而在事情平息下來的時候再回到她的移動應(yīng)用開發(fā)工作。換句話說，這種模式同時平衡了個人和集體的生產(chǎn)力。此外，由于開發(fā)者對自己工作之外的其他領(lǐng)域已經(jīng)有了一定的了解（即可以學(xué)到一些新知識），所以這種模式在風(fēng)險減輕和開發(fā)者的幸福感之間起到了很好的平衡。

管理權(quán)的重要之處在于，盡管不像所有權(quán)那樣正式，但是它還是被清楚地界定和實(shí)施。該模式下至少有一些事情要做：應(yīng)當(dāng)有一份管理者清單，可以定義每個管理者的管理范圍；GitHub（或者其他 SCM 工具）應(yīng)當(dāng)被配置成由管理者批準(zhǔn)所有的拉取請求，并且管理者應(yīng)當(dāng)有充足的時間對其組件進(jìn)行必要的“管理”。如果這方面沒有特定的形式和紀(jì)律，所有的事情都會順著滑坡滑下去，直至處于自由競爭的坑中。

接管權(quán)模式

最后，一種在大型組織中非常流行的模式可能也很重要，就是“接管權(quán)”，有少數(shù)被選中的人（通常是宇航員架構(gòu)師）負(fù)責(zé)“擁有”一切。他們擁有豐富的知識、作出重大的技術(shù)決策，并設(shè)計業(yè)務(wù)邏輯和結(jié)構(gòu)，但實(shí)際的具體工作由每個開發(fā)者來完成，而且往往是以自由競爭的方式進(jìn)行。

這種模式在理論上非常有效。通過接管者與動手的開發(fā)者分享他們的“智慧”，為快速、高效的解決方案開辟了一條途徑，實(shí)現(xiàn)了效率和質(zhì)量的優(yōu)化。有了接管者的協(xié)助，開發(fā)者可以自由出入代碼庫，并通過接管者來迅速進(jìn)入狀態(tài)。

但在實(shí)踐中從未產(chǎn)生過這種影響。沒有任何實(shí)踐經(jīng)驗(yàn)的接管者會迅速與技術(shù)現(xiàn)實(shí)脫節(jié)，而且不能真正幫助開發(fā)者實(shí)現(xiàn)某些改進(jìn)或修補(bǔ)某些 Bug。開發(fā)者可能要耗費(fèi)相同的時間去改進(jìn)，同時，由于基本上將自己的自主權(quán)（和創(chuàng)造力）交給了那些能夠指揮他們的接管者，所以他們可能會感到挫敗。

作為一個曾經(jīng)扮演過接管者角色的人，我認(rèn)為這種模式對任何人都很糟糕，這就是為什么我盡量避免這種類型的角色。

這些只是我遇到的幾種分工模式，我也很想聽聽你的想法和經(jīng)驗(yàn)。

作者介紹：

Ben Northrop，畢業(yè)于卡耐基梅隆大學(xué)，自詡“老”程序員，寫博客將近 20 年。2017 年，創(chuàng)辦了 Highline Solutions，是一家專注軟件架構(gòu)和全棧開發(fā)的咨詢公司。

原文鏈接：

https://bennorthrop.com/Essays/2022/code-ownership-stewardship-or-free-for-all.php