软件工程资料汇编

企业的IT部门被很多事情困扰着，但过度的复杂性一定是在名单的首位。任何试图描述平均IT景观的努力，最终都会在应用、硬件和相互依存关系中变成无法解读的意大利面条。这几乎就像企业IT受到热力学第二定律的制约，该定律的结论是一个（孤立的）系统中的熵永远不会减少--在最好的情况下它可能是恒定的，但通

测试在现代软件开发中的重要性怎么强调都不为过。交付一个成功的产品不是你做一次就忘记的事情，而是一个不断重复的过程。随着每一行代码的更改，软件必须保持功能状态，这意味着需要进行严格的测试。随着时间的推移，随着软件行业的发展，测试实践也日趋成熟。逐渐走向自动化，测试方法影响了软件设计本身

如何实现去火星？ 瀑布：计划你要到火星；构建火箭；测试火箭，你到了火星。 敏捷：你可能要到火星；开始建设火箭；然后发现你是去天王星，最后你到了月球。 看板：你要到火星；你把工作划分为数千个片段；一年后你还在等火箭座位的扶手完工。 SCRUM：你要为火箭

本文《Agile as Trauma》指出敏捷的本质是反动的（reactionary：保守、落后、反动）。敏捷就像任何概念一样，必须适应和学习，将产品管理和领域驱动设计的方法与敏捷相结合是我们今天所处的位置，但这种组合还没有被命名。原文点击标题：

我不想写这篇文章，但我已经开始看到很多人指责 Rust 项目中长期存在的问题被推向了错误的方向。现在审核组辞职了，感觉有话要说。以下是我与核心团队的经验分享。这些不一定与审核团队的辞职直接相关，但我认为是核心团队内部系统性问题的象征。我还想说，这主要与新任命的核心团队成员无关，这些问题一直是

用于定义团队 API 的模板。基于Matthew Skelton @matthewskelton和 Manuel Pais 

软件工程的巧妙之处在于它是一个适合通才蓬勃发展的领域：逻辑与解谜、产品设计与用户反馈、写作与沟通、想象力、架构、团队合作，一应俱全。

软件物料清单 (SBOM) 正成为一项至关重要的安全要求，它可以在软件在整个供应链中移植时实现可见性。组织必须立即采取行动，建立一项重要的新能力：SBOM 管理。目前，行业领导者采用的最佳实践是为应用程序的每个交付或部署版本生成软件材料清单SBOM，生成并管理软件的物料清单 (SBO

大多数工程组织都专注于交付项目。他们应该专注于里程碑。管理项目很困难。公司会为了做好这件事而扭曲自己。与其下棋，不如改用跳棋。里程碑是一个更简单的游戏，你会得到更好的结果。在这篇文章中，我描述了：我建议您采用一种特殊的里程碑。为什么人类很讨厌

改善交付时间应该是每个组织的目标。阻碍交付流程加速的一个主要减速器是组织中的不同团队传统上一直在孤岛中工作。为了解决这个问题，在大多数情况下会出现一个简单的解决方案：增加不同团队之间的沟通。但是，这个解决方案就足够了吗？当公司成长时，“增量沟通解决方案”如何扩展？我们将在本文中解释其

在我们作为工程师的职业生涯的早期，我们被告知要投资于技术技能。我们学习语言，实现模式和框架，跨堆栈架构，并学习如何扩展。进入工作的杂草是让你在队友中获得可信度和影响力的原因。但为了更成功地进行技术调用和提升职业生涯，工程师实际上需要培养更好的战略决策技能——而不仅仅是技术执行技能。事

站点可靠性工程 (SRE) 的实践在2022年如何？ 随着可靠性成为公司运营能力的基础，我们预测 SRE 角色将发挥其真正潜力，而不是受到部分实施的限制。如果 SRE 目前像机械师一样，在汽车发生碰撞时修理汽车，那么未来 SRE 将变得更像土木工程师，更多地专注于为汽

Zach Lloyd曾是谷歌的首席工程师，负责谷歌表单团队。之后，他在《时代周刊》担任临时CTO，现在是一家建立基于Rust的终端的创业公司的CEO。他还在出版一本手册，记录他作为CTO/工程经理的管理风格。这是他关于他看到的工程师所犯的最大错误的一个帖子的摘要。 <

这里有一些我相信的关于软件工程的令人不安的事实！（banq：令人焦虑？） ... 具有特殊语法的复杂 DSL 可能是死胡同。Ruby 和 Scala 都非常重视这一点，但都没有让它流行起来。 如果没有其他因素，静态类型语言比动态类型语言更适合大型项目。对此没有

软件开发中的设计模式是解决常见问题的可重复解决方案和最佳实践。即使在服务监控的情况下，如果使用得当，设计模式也可以帮助团队接受服务所有权并解决生产中的服务故障。您可以将服务监控设计模式分为三类：健康检查你怎么知道你的服务正在运行——如果是的话——也在做它应该做的事情？是否及时

如何在敏捷世界中交付可靠的架构？这是一种创建适应不断变化的架构的方法。有很多关于敏捷架构的文章，但我认为我们还没有一个公认的实践。好的架构必须考虑许多不同的观点（技术和人的），并不断地权衡一个与另一个。 MVP 论点有