作者 | 核子可樂、褚杏娟
近日，十多年從事開發工作的 Facundo Olano 寫了一篇關于“軟件開發應該優先服務誰”的文章，引發了廣發開發者討論。Facundo 在文章中提出，業務和用戶的優先級永遠大于維護者，維護者大于開發者，但對于業務和用戶的優先級，則無法確定。
對此，有開發者提出，開發人員其實必須滿足的是中層管理人員的需求，而不是實際用戶的需求，否則就拿不到訂單。那么，在這個研發生態里，開發者明顯處于底層，那誰才處于“食物鏈的頂端”？
“代碼的閱讀次數大于編寫次數。”相信很多程序員朋友都聽過這句話，它提醒我們作為代碼開發者，絕不應犧牲未來的閱讀和修改空間來換取一己之便利。換句話說，代碼的閱讀量要多于編寫量，所以最好想辦法保證代碼簡潔明了，同時輔以測試和說明文檔等有助于提高可維護性的要素。
我個人則將其總結為更簡潔的表達方式：
維護者>作者
其實在代碼編寫之外，這樣一條經驗法則也同樣適用于發現問題和做出決策。
代碼是用來跑的，不是用來讀的
代碼只是我們達成目的的手段。軟件都有自己的目的，負責為特定用戶提供服務。如果代碼無法達成這項目的、為用戶提供良好的體驗，那么無論代碼本身質量多高、可維護性多棒、涉及的技術有多么精妙，都將毫無意義。因此：
用戶>維護者>作者
或者說，我們把開發者部分統一起來，就得到了：
用戶>開發者
正因為如此，我們才應該盡早、盡快把程序交付給用戶，再結合他們的反饋不斷做出優化，而不是在事前做一大堆假設、或者反復詢問他們到底想要什么。
這是一套強有力的思維模型，只要在開發過程中始終以用戶為中心，我們就能走得更遠、更穩。這也是我自己在漫長的職業生涯中，總結出的最具指導意義的開發方針。
代碼的運行次數大于閱讀次數
當我說到“運行”時，指的可不只是執行程序，更包括生產運營中的各個環節：部署、升級、觀察、審計、監控、修復、清退等。正如 Dan McKinley 所言：
“總的來說，保持系統長期可靠運行的成本，要遠遠優先于構建系統時遇到的種種不便。”
我們也可以把這個結論納入前文提到的小模型：
用戶 > 運維者 > 開發者
我本人花了很長時間才吃透這一點。因為根據個人經驗，實際構建的很多軟件都從未真正被投入生產，至少沒有得到大規模應用。這是因為大部分軟件都建立在未經測試的假設之上。
在生產環境中運行代碼時，保持簡單/保持傻瓜設計這看似直白的原則往往很難落地。它指的不只是代碼本身，更要求減少軟件中的活動部件、吃透軟件的故障模式。換言之，要保證某些部件出了問題時軟件仍能正常工作。
別忘了，是軟件在為業務服務
要想讓開發過程平穩推進，核心要素在于用戶。而這其中蘊含的假設是：軟件本身有用且運行良好，軟件對用戶有價值、對組織也有價值。這樣的提前可以轉化成以下理解方式：開發者需要編寫出良好、可用的軟件，業務部門再將其轉化成經濟收益。
另外，軟件應該總體有效，更好地服務于消費者和企業需求。通過納入業務視角，我們的基本方針進一步擴充成這樣的形式：
業務 > 用戶 > 運維者 > 開發者
最典型的例子就是預算：我們不可能有無限的資源來滿足用戶需求，所以首先要衡量成本和收益，想清楚怎樣設置營銷活動和上市期限。此外還有利益相關方和投資者，他們各有各有利益和訴求。
在如此復雜的情況下，乍看上去對于軟件、開發團隊或用戶似乎正向的決策，放進整個組織內往往會起到負面作用。有時候，我們更需要創造收入、而不只是取悅用戶。
反面教材
到這里我們就得到了一個小模型，表達了軟件開發流程中各個因素之間的相對重要度，也許能幫助大家立足宏觀專注于真正關鍵的環節。接下來，我們將著眼于常見的軟件開發障礙，嘗試把它們也納入思維模型。
不可維護的代碼：作者 > 維護者
這就是我們文章開頭提到的情況，開發者聰明但太懶惰，于是寫出的代碼就成了交纏混雜的意大利面，后續的接手者永遠無法理解當初為什么要這樣設計。
無用的軟件：開發者 > 用戶
對于那些不在乎用戶感受、或者堅持把技術放在首次的團隊，開發的就是這種無用軟件。其中充斥著過度設計、降低用戶體驗的“現代化”元素，Web 應用程序甚至有可能導致瀏覽器崩潰。
在我的機器上明明能跑：開發者 > 運維者
軟件在設計中并未考慮到運維需求，因此軟件本身過于復雜、包含大量移動部件、專供小型數據負載使用的數據庫、由眾多小團隊管理的微服務生態等等。總之，軟件架構在毫無必要時就開始考慮后續的規模擴展問題，最終運維人員被折磨得焦頭爛額、開發人員也被批得體無完膚。
技術倒逼業務：開發者 > 業務
把代碼本身視為目的。那幫自命不凡的工匠、泰坦尼克號上的音樂家和 Lisp 極客們，搞出來的就是這樣的軟件。
簡歷驅動型開發：開發者 > 一切
不加任何約束、任由開發者天馬行空發揮之下，開發出的就是這種軟件。
純粹空想型軟件：業務 > 用戶 > ops 開發者
這種軟件雖然能被開發出來，但卻很少、甚至從未被投入生產。我個人稱之為空想型軟件，因為它完全是按照業務部門的想象搞出來的。
業務 > user >運維者 > 開發者
這是另外一種沒考慮過用戶需求的空想型軟件，它根本就解決不了問題、或者解決的是錯誤/根本不存在的問題。這類軟件會倒逼用戶向它靠攏，為的就是讓大量前期投資看起來能有那么一點點用處。
極端資本主義軟件：biz > 用戶 > 運維者 > 開發者
這是由風險投資支撐而來的軟件，沒有健康的商業模式，或者說商業模式只追求不斷增長、達成壟斷、剝削用戶。
一點總結
最后，讓我們為這場有趣的思想實驗做個收尾：
業務 > 用戶，這會帶來難以估量的災難后果。
如前文提到，我們之所以要開發軟件，目的是為最終用戶解決問題。《程序員修煉之道》就對此做出過精當的總結：我們的目標是取悅用戶，而不僅僅是交付代碼。但自從投身于程序開發之后，我發現隨著軟件普及度的不斷提升，這個假設又變得越來越不受重視、難以維持。
當下很多得到大規模應用的軟件根本就不關心用戶，甚至反過來要操縱用戶、把用戶變成產品的一部分。這不僅限于社交媒體——作為用戶，我們甚至無法回避各種頁面和功能欄中的廣告彈窗，谷歌搜索里顯示的垃圾也越來越多。
在我看來，好軟件的定義已經跟行業中大部分認為的能賺錢的軟件之間出現了嚴重割裂，很多軟件專家的強烈不適感也正來源于此。雖然我們不能忽視軟件開發領域的底層商業邏輯，但至少應該采取更強硬的道德立場、拒絕無止境地傷害用戶。用戶也許并不永遠優先于業務，但業務也不該被無條件地放在首位：
用戶 > 運維者 > 開發者
業務 > 運維者 > 開發者
業務 ? 用戶
網友：實際上你必須考慮管理層
Facundo 的文章引起了廣發開發者共鳴，同時這些開發者們結合自己的實際經歷又做了一些補充，比如管理層的關鍵作用。
有開發者直接指出，有些用戶使用某個系統并不是因為他們喜歡它，而是因為他們的公司購買了它。“在‘業務>用戶’的情況下，開發人員最終不得不迎合中層管理人員的需求，而不是實際用戶。不這樣做的代價就是無法贏得合同。但當你忙于實現中層管理喜歡的新功能時，用戶的需求就會被鎖定在你有限時間里能提供的‘垃圾’里。”
“我有過這樣的經歷。我在一家向市政府銷售軟件的公司工作。重要的是市長/鎮長/市議會的意見。如果報告看起來不錯并且價格合適，他們就會續訂。我記得在會議現場，每天使用它的人當面告訴我們它有多么糟糕。毫無疑問，該網站承諾將修復一些特定的 bug，并將價格提高到最低限度。” 網友“Deprecate9151”提到。
“derangedHorse”指出，“通常，中層管理人員也是用戶，但他們只占用戶群的少數，并且使用一組不同的功能（例如報告）。因此，現在的問題是哪些用戶被優先考慮，并在優先考慮少數擁有權力的用戶的體驗與保持產品足夠的可用性以供其他用戶提供一些數據價值之間找到平衡。”
對此，有開發者指出，“您需要考慮中層管理人員的需求，因為他們付錢給您，但通常還有工藝空間為最終用戶帶來真正出色的用戶體驗。大多數軟件工程師都缺乏真正的工藝意識，因此當不需要構建出色的用戶體驗時，他們通常不會理會這個。”
參考鏈接：
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
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
