針對一封詢問身為研究物理學家如何學習軟體設計技巧的電子郵件，我的回覆如下：
我職業生涯早期曾隸屬於一個生物資訊實驗室，所以我認為我理解你所說的「科學程式碼」現象。我的想法是：
第一個總體觀察是，「軟體設計」是透過實踐學習的最佳方式。雖然我在大學上過一些正式的「設計」課程，甚至還擔任過我們課程專案的「架構師」，但那些大多是假裝的，就像幼稚園小朋友玩消防員遊戲一樣。真正教會我如何做事的是我職業生涯中的一個意外，我的第二個真正專案（IntelliJ Rust）讓我擔任了軟體領導職位，並讓設計成為我的問題。我在 IJ Rust 中犯了一些錯誤，但沒有什麼太糟糕的，我學到了很多。所以這是個好消息——軟體工程足夠簡單，一個好奇的心靈可以從基本原理（和閱讀隨機的部落格文章）中弄清楚它。
第二個總體觀察，壞消息是：康威定律很重要。軟體生成會重複生產軟體的組織的社會架構。或者，正如 neugierig 巧妙地所說：
如果我必須用一句話總結我學到的東西，那就是：我們談論程式設計，好像它與寫程式碼有關，但最終程式碼的重要性不如架構，而架構的重要性不如社會問題。
我懷疑你感知到的工業軟體與科學軟體之間的差異，並非在於軟體建構知識，而是驅使人們生產軟體的激勵機制領域。例如「我的博士論文需要在三個月內發表一篇論文」可能是一個重要的解釋因素？
這裡有兩件事你可以做。一、有時你會得到機會為一個專案設計或推動一個激勵結構。這機會非常難得，但影響力極大。這就是 TIGER_STYLE 背後的秘訣，並非規則本身，而是讓這套規則變得有意義的社會背景。
二、你可以加速經歷四個階段的悲傷，最終接受。激勵結構幾乎從來都不是你想要的樣子，但如果你無法改變它，你可以適應它。這也適用於大多數工業軟體專案——總沒有時間把事情做好，你必須在限制下盡力而為。
讓我以 rust-analyzer 為例。該專案的物理現實是，它既非常深入（它是一個編譯器！太棒了！）又非常廣泛（與 LLM 相反，經典 IDE 包含大量專門設計的特殊功能）。社會現實是，「深入的編譯器」可以吸引一些才華橫溢的專注貢獻者，而「廣泛的功能」則非常適合一大群週末戰士，他們是學習 Rust 的人，沒有持續參與專案的能力，但可以花一兩個小時來解決自己的問題。
我堅持 rust-analyzer 不需要建構 rustc，它建立在穩定版之上，沒有任何 C 依賴，並且整個測試套件只需幾秒鐘，這都是為了吸引高影響力貢獻者的目標。我一直在調整建構系統，以確保人們可以在不考慮其他任何事情的情況下處理 borrow checker。
為了吸引週末戰士，rust-analyzer 的內部被分成多個獨立的功能，每個功能在運行時都由 catch_unwind 保護。我的想法是，我明確地不想過度關心那裡的品質，讓功能 PR 的門檻是「快樂路徑有效且經過測試」。程式碼崩潰也沒關係，只要滿足以下條件，它只會吸引更多貢獻者：
相比之下，在處理提供功能支援的核心骨幹時，我對品質的要求非常嚴格。
關於適應而非修復激勵結構，有一點需要謹慎——未來是不確定的，並且往往以最不方便的方式發生。rust-analyzer 實驗的最初動機是避免編寫平行編譯器（IntelliJ Rust 中的那個）的需要，並為 LSP 原型化一個更好的架構，以便學習到的東西可以回溯到 rustc。所以，即使在核心（尤其是在核心），程式碼也非常實驗性。唉。看來我又得面對另一個編譯器了？
我猜測 uutils 專案也發生了類似的事情，它最初是人們學習 Rust 的主要目的地，最終變成了 Ubuntu coreutils 的實現。
第三，現在談一些具體的建議。可惜，我不知道有任何一本書可以推薦，其中包含這些真理。我懷疑這樣的書只能在博爾赫斯的一則寓言短篇故事中找到：實踐似乎是這裡不可或缺的元素。但以下是一些值得關注的事情：
Gary Bernhardt 的 Boundaries 演講是我最喜歡的。它包含了紮實的物件層面建議，對我來說，它觸發了總體探究。
How to Test 是我希望我擁有的。我立即理解了測試的重要性，但花了很長時間才變得足夠自大，承認大多數被廣泛引用的測試建議都是巫醫的江湖騙術，並概念化了真正有效的方法。
∅MQ guide，以及更廣泛地說，Pieter Hintjens 的著作，讓我接觸到了康威定律的思考。rust-analyzer 的「功能開發」架構？——樂觀合併，已應用。
Jamii 的 Reflections on a decade of coding 非常出色，總體性很強。它是我連結的第一個連結，是故意的。
Ted Kaminski 的部落格是關於軟體開發連貫理論最接近的東西，恰當地被組織成一本不存在的書的筆記！
至於實際的書籍，《Software Engineering at Google》和 Ousterhout 的《The Philosophy of Software Design》經常被推薦。它們都很好。特別是 SWE，幫助我認識了一些重要的名字。但對我來說，它們並沒有帶來突破性的啟發。