学习软件架构

在回复一封询问作为研究物理学家学习软件设计技能的电子邮件时：我在职业生涯早期曾加入过生物信息学实验室，所以我想我理解你在说什么，即“科学代码”现象！我的想法：第一个元观察是“软件设计”最好是通过实践来学习。虽然我在大学上过一些正式的“设计”课程，而且我什至是我们课程项目的“建筑师”，但这些东西大多是虚构的，幼儿园小朋友扮演消防员。真正教会我如何做事的是我职业生涯的一次意外，我的第二个真正的项目（IntelliJ Rust）将我推到了软件领导的位置，并使设计成为我的问题。我在 IJ Rust 中确实犯了一些错误，但没什么太可怕的，而且我学到了很多东西。所以这是个好消息——软件工程非常简单，好奇的头脑可以从基本原理（以及阅读随机的博客文章）中找出答案。第二个元观察，坏消息：康威定律很重要。 Softwaregenesis 重复了生产软件的组织的社会架构。或者，正如 neugierig 雄辩地说的那样，如果我用一句话来总结我学到的东西，那就是：我们谈论编程就像谈论编写代码一样，但代码最终不如架构重要，而架构最终也没有社会问题重要。我怀疑您所感知的工业软件和科学软件之间的差异与其说与软件构建知识有关，不如说与迫使人们生产软件的激励领域有关。像“我的博士需要在三个月内发表论文”之类的东西也许是一个重要的解释？您可以在这里做两件事。第一，有时您有机会设计或推动项目的激励结构。这种情况虽然千载难逢，但却影响深远。这是 TIGER_STYLE 背后的秘密武器，不是规则集本身，而是使这组规则成为好主意的社会背景。第二，你可以快速经历悲伤的四个阶段，直到接受。激励结构几乎从来不是你想要的那样，但是，如果你无法改变它，你可以适应它。对于大多数工业软件项目来说也是如此——永远没有时间正确地做一件事，你必须在有限的条件下尽你所能。让我以 rust-analyzer 为例。该项目的物理现实是，它同时非常深入（它是一个编译器！耶！）并且非常广泛（与 LLM 相反，经典 IDE 具有许多专门构建的特殊功能）。社会现实是，“深度编译器”可以吸引一些才华横溢的敬业贡献者，而“广度功能”可能非常适合一群周末战士、学习 Rust 的人，他们没有持续参与该项目的能力，但可以花一两个小时来止痒。我坚持认为 rust-analyzer 不需要构建 rustc ，它建立在稳定的基础上，它没有任何 C 依赖项，并且整个测试套件只需几秒钟，这是为了吸引高影响力贡献者的目标。我正在对构建系统进行争论，以确保人们可以在借用检查器上工作而无需考虑其他任何事情。为了吸引周末战士，rust-analyzer 的内部被分成多个独立的功能，其中每个功能在运行时由 catch_unwind 保护。我的想法是，我明确不想太关心那里的质量，获得功能 PR 的标准是“快乐路径有效且经过测试”。如果代码崩溃也没关系，它只会吸引更多的贡献者，前提是：质量与功能隔离，并且不会溢出，在运行时，崩溃对用户来说是不可见的（至关重要的是 rust-analyzer 功能与不可变的快照一起工作，并且不会毒害数据）。相比之下，当研究为功能提供支持的核心脊柱时，我对质量相对更加迂腐。关于适应而不是固定激励结构的一个警告是——未来是不确定的，而且往往会以最不方便的方式发生。 rust-analyzer 实验背后的最初动机是为了避免编写并行编译器（IntelliJ Rust 中的编译器）的需要，并为 LSP 构建更好的架构原型，以便将学习内容向后移植到 rustc 。因此，即使在核心中（尤其是在核心中），代码也是非常实验性的。那好吧。我猜现在又被一个编译器困住了？我可能会猜测 uutils 项目也发生了类似的事情，该项目最初是人们学习 Rust 的主要目的地，最终成为 Ubuntu coreutils 的实现。第三，现在提出一些具体建议。可悲的是，我不知道有哪一本书可以推荐其中包含真相。我怀疑人们只能在博尔赫斯的一部杜撰的短篇小说中找到这样一本书：实践似乎