作者 | 核子可樂、褚杏娟

近日，十多年從事開發(fā)工作的 Facundo Olano 寫了一篇關于“軟件開發(fā)應該優(yōu)先服務誰”的文章，引發(fā)了廣發(fā)開發(fā)者討論。Facundo 在文章中提出，業(yè)務和用戶的優(yōu)先級永遠大于維護者，維護者大于開發(fā)者，但對于業(yè)務和用戶的優(yōu)先級，則無法確定。

對此，有開發(fā)者提出，開發(fā)人員其實必須滿足的是中層管理人員的需求，而不是實際用戶的需求，否則就拿不到訂單。那么，在這個研發(fā)生態(tài)里，開發(fā)者明顯處于底層，那誰才處于“食物鏈的頂端”？

“代碼的閱讀次數(shù)大于編寫次數(shù)。”相信很多程序員朋友都聽過這句話，它提醒我們作為代碼開發(fā)者，絕不應犧牲未來的閱讀和修改空間來換取一己之便利。換句話說，代碼的閱讀量要多于編寫量，所以最好想辦法保證代碼簡潔明了，同時輔以測試和說明文檔等有助于提高可維護性的要素。

我個人則將其總結為更簡潔的表達方式：

維護者>作者

其實在代碼編寫之外，這樣一條經(jīng)驗法則也同樣適用于發(fā)現(xiàn)問題和做出決策。

代碼是用來跑的，不是用來讀的

代碼只是我們達成目的的手段。軟件都有自己的目的，負責為特定用戶提供服務。如果代碼無法達成這項目的、為用戶提供良好的體驗，那么無論代碼本身質量多高、可維護性多棒、涉及的技術有多么精妙，都將毫無意義。因此：

用戶>維護者>作者

或者說，我們把開發(fā)者部分統(tǒng)一起來，就得到了：

用戶>開發(fā)者

正因為如此，我們才應該盡早、盡快把程序交付給用戶，再結合他們的反饋不斷做出優(yōu)化，而不是在事前做一大堆假設、或者反復詢問他們到底想要什么。

這是一套強有力的思維模型，只要在開發(fā)過程中始終以用戶為中心，我們就能走得更遠、更穩(wěn)。這也是我自己在漫長的職業(yè)生涯中，總結出的最具指導意義的開發(fā)方針。

代碼的運行次數(shù)大于閱讀次數(shù)

當我說到“運行”時，指的可不只是執(zhí)行程序，更包括生產(chǎn)運營中的各個環(huán)節(jié)：部署、升級、觀察、審計、監(jiān)控、修復、清退等。正如 Dan McKinley 所言：

“總的來說，保持系統(tǒng)長期可靠運行的成本，要遠遠優(yōu)先于構建系統(tǒng)時遇到的種種不便。”

我們也可以把這個結論納入前文提到的小模型：

用戶 > 運維者 > 開發(fā)者

我本人花了很長時間才吃透這一點。因為根據(jù)個人經(jīng)驗，實際構建的很多軟件都從未真正被投入生產(chǎn)，至少沒有得到大規(guī)模應用。這是因為大部分軟件都建立在未經(jīng)測試的假設之上。

在生產(chǎn)環(huán)境中運行代碼時，保持簡單/保持傻瓜設計這看似直白的原則往往很難落地。它指的不只是代碼本身，更要求減少軟件中的活動部件、吃透軟件的故障模式。換言之，要保證某些部件出了問題時軟件仍能正常工作。

別忘了，是軟件在為業(yè)務服務

要想讓開發(fā)過程平穩(wěn)推進，核心要素在于用戶。而這其中蘊含的假設是：軟件本身有用且運行良好，軟件對用戶有價值、對組織也有價值。這樣的提前可以轉化成以下理解方式：開發(fā)者需要編寫出良好、可用的軟件，業(yè)務部門再將其轉化成經(jīng)濟收益。

另外，軟件應該總體有效，更好地服務于消費者和企業(yè)需求。通過納入業(yè)務視角，我們的基本方針進一步擴充成這樣的形式：

業(yè)務 > 用戶 > 運維者 > 開發(fā)者

最典型的例子就是預算：我們不可能有無限的資源來滿足用戶需求，所以首先要衡量成本和收益，想清楚怎樣設置營銷活動和上市期限。此外還有利益相關方和投資者，他們各有各有利益和訴求。

在如此復雜的情況下，乍看上去對于軟件、開發(fā)團隊或用戶似乎正向的決策，放進整個組織內往往會起到負面作用。有時候，我們更需要創(chuàng)造收入、而不只是取悅用戶。

反面教材

到這里我們就得到了一個小模型，表達了軟件開發(fā)流程中各個因素之間的相對重要度，也許能幫助大家立足宏觀專注于真正關鍵的環(huán)節(jié)。接下來，我們將著眼于常見的軟件開發(fā)障礙，嘗試把它們也納入思維模型。

不可維護的代碼：作者 > 維護者

這就是我們文章開頭提到的情況，開發(fā)者聰明但太懶惰，于是寫出的代碼就成了交纏混雜的意大利面，后續(xù)的接手者永遠無法理解當初為什么要這樣設計。

無用的軟件：開發(fā)者 > 用戶

對于那些不在乎用戶感受、或者堅持把技術放在首次的團隊，開發(fā)的就是這種無用軟件。其中充斥著過度設計、降低用戶體驗的“現(xiàn)代化”元素，Web 應用程序甚至有可能導致瀏覽器崩潰。

在我的機器上明明能跑：開發(fā)者 > 運維者

軟件在設計中并未考慮到運維需求，因此軟件本身過于復雜、包含大量移動部件、專供小型數(shù)據(jù)負載使用的數(shù)據(jù)庫、由眾多小團隊管理的微服務生態(tài)等等?？傊?，軟件架構在毫無必要時就開始考慮后續(xù)的規(guī)模擴展問題，最終運維人員被折磨得焦頭爛額、開發(fā)人員也被批得體無完膚。

技術倒逼業(yè)務：開發(fā)者 > 業(yè)務

把代碼本身視為目的。那幫自命不凡的工匠、泰坦尼克號上的音樂家和 Lisp 極客們，搞出來的就是這樣的軟件。

簡歷驅動型開發(fā)：開發(fā)者 > 一切

不加任何約束、任由開發(fā)者天馬行空發(fā)揮之下，開發(fā)出的就是這種軟件。

純粹空想型軟件：業(yè)務 > 用戶 > ops 開發(fā)者

這種軟件雖然能被開發(fā)出來，但卻很少、甚至從未被投入生產(chǎn)。我個人稱之為空想型軟件，因為它完全是按照業(yè)務部門的想象搞出來的。

業(yè)務 > user >運維者 > 開發(fā)者

這是另外一種沒考慮過用戶需求的空想型軟件，它根本就解決不了問題、或者解決的是錯誤/根本不存在的問題。這類軟件會倒逼用戶向它靠攏，為的就是讓大量前期投資看起來能有那么一點點用處。

極端資本主義軟件：biz > 用戶 > 運維者 > 開發(fā)者

這是由風險投資支撐而來的軟件，沒有健康的商業(yè)模式，或者說商業(yè)模式只追求不斷增長、達成壟斷、剝削用戶。

一點總結

最后，讓我們?yōu)檫@場有趣的思想實驗做個收尾：

業(yè)務 > 用戶，這會帶來難以估量的災難后果。

如前文提到，我們之所以要開發(fā)軟件，目的是為最終用戶解決問題?！?span id="cvzb2ti" class="candidate-entity-word" data-gid="2715329">程序員修煉之道》就對此做出過精當?shù)目偨Y：我們的目標是取悅用戶，而不僅僅是交付代碼。但自從投身于程序開發(fā)之后，我發(fā)現(xiàn)隨著軟件普及度的不斷提升，這個假設又變得越來越不受重視、難以維持。

當下很多得到大規(guī)模應用的軟件根本就不關心用戶，甚至反過來要操縱用戶、把用戶變成產(chǎn)品的一部分。這不僅限于社交媒體——作為用戶，我們甚至無法回避各種頁面和功能欄中的廣告彈窗，谷歌搜索里顯示的垃圾也越來越多。

在我看來，好軟件的定義已經(jīng)跟行業(yè)中大部分認為的能賺錢的軟件之間出現(xiàn)了嚴重割裂，很多軟件專家的強烈不適感也正來源于此。雖然我們不能忽視軟件開發(fā)領域的底層商業(yè)邏輯，但至少應該采取更強硬的道德立場、拒絕無止境地傷害用戶。用戶也許并不永遠優(yōu)先于業(yè)務，但業(yè)務也不該被無條件地放在首位：

用戶 > 運維者 > 開發(fā)者

業(yè)務 > 運維者 > 開發(fā)者

業(yè)務 ? 用戶

網(wǎng)友：實際上你必須考慮管理層

Facundo 的文章引起了廣發(fā)開發(fā)者共鳴，同時這些開發(fā)者們結合自己的實際經(jīng)歷又做了一些補充，比如管理層的關鍵作用。

有開發(fā)者直接指出，有些用戶使用某個系統(tǒng)并不是因為他們喜歡它，而是因為他們的公司購買了它?！霸凇畼I(yè)務>用戶’的情況下，開發(fā)人員最終不得不迎合中層管理人員的需求，而不是實際用戶。不這樣做的代價就是無法贏得合同。但當你忙于實現(xiàn)中層管理喜歡的新功能時，用戶的需求就會被鎖定在你有限時間里能提供的‘垃圾’里。”

“我有過這樣的經(jīng)歷。我在一家向市政府銷售軟件的公司工作。重要的是市長/鎮(zhèn)長/市議會的意見。如果報告看起來不錯并且價格合適，他們就會續(xù)訂。我記得在會議現(xiàn)場，每天使用它的人當面告訴我們它有多么糟糕。毫無疑問，該網(wǎng)站承諾將修復一些特定的 bug，并將價格提高到最低限度?！?網(wǎng)友“Deprecate9151”提到。

“derangedHorse”指出，“通常，中層管理人員也是用戶，但他們只占用戶群的少數(shù)，并且使用一組不同的功能（例如報告）。因此，現(xiàn)在的問題是哪些用戶被優(yōu)先考慮，并在優(yōu)先考慮少數(shù)擁有權力的用戶的體驗與保持產(chǎn)品足夠的可用性以供其他用戶提供一些數(shù)據(jù)價值之間找到平衡?！?/span>

對此，有開發(fā)者指出，“您需要考慮中層管理人員的需求，因為他們付錢給您，但通常還有工藝空間為最終用戶帶來真正出色的用戶體驗。大多數(shù)軟件工程師都缺乏真正的工藝意識，因此當不需要構建出色的用戶體驗時，他們通常不會理會這個。”

參考鏈接：

https://olano.dev/2023-11-30-code-is-run-more-than-read/

https://news.ycombinator.com/item?id=38483181

本文轉載來源：

https://www.infoq.cn/article/NM15aIhUo7KUahoyWKZ5