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

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

這支團隊已經創(chuàng)建并支持一款移動應用、一項 Alexa 技能、三款獨立的網絡應用和十五個微服務。

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

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

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

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

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

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

影響因素

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

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

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

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

所有權模式

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

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

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

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

自由競爭模式

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

盡管這樣的策略的確可以保證總體分配均衡（即 Emily 在沒有移動工作的時候也不會無所事事，因為她被拉去處理 Python 服務），但這種模式可能既累人，又充滿質量問題。如果我們沒有與我們所從事的代碼庫建立長久聯(lián)系，那么我們的工作就只是權宜之計，并以無知為指導。我們在短期內采用了一種古怪的修復方法，因為不知道更好的辦法，或者我們并不關心——下一次 Sprint 我們就會在不同的代碼庫里了！正如他們所說，“誰也不會把租來的汽車洗干凈?！?/span>

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

管理權模式

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

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

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

接管權模式

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

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

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

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

這些只是我遇到的幾種分工模式，我也很想聽聽你的想法和經驗。

作者介紹：

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

原文鏈接：

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