软件工程资料汇编

本文启发来自 Gregor Hohpe的一篇文章（关于架构策略的参考，有许多关于此主题的

宁可相信 10 倍的上下文和环境......在哲学上，比赛的获胜者是跑得最慢的人。或者：最后到达那里的人（维特根斯坦，文化和价值）如果10倍开发人员位于一个开发团队中，这个团队与需求以及技术架构之间组成一个复杂系统，而缓慢对于复杂系统是重要的。

自从Scaled Agile Framework（简称SAFe）在4.5版中采用

英文中responsibility和accountability两个词语有明显区分，但是中文中却没有，负责、责任、责备、问责都混淆一起，导致人们傻傻分不清楚，要么承担责任过多，压力太大；要么过分轻松，生命不能承受之轻，关键是我们的词语中没有对两者严谨的区分，区分差异是我们迈向思考的第一步。<

测试的主题是广泛的。从外面看起来可能很简单，但事实并非如此。例如，人们可以将测试定义为检查软件是否适合其目的。 1. 单元测试单元测试是一门有据可查的学科：无论使用哪种语言，都已经出版了大量关于该主题的书籍。他们通常重复相同的事情。<

在当今瞬息万变的市场中开发现代SaaS产品，需要克服各种极端不确定性，需要比Scrum还要敏捷得多的东西！让我们面对现实吧！ Scrum真的不是那么敏捷：我已经拥有20多年的Scrum，足够长了！当时转向使用Scrum无疑是在敏捷阶梯上的进步，但是因为在我整个职业生涯中都一直再使用S

由中央高智能部门协调和控制软件的大批量发布经常会失败，其原因是由于数学NP问题以及人类之间的弱相互影响。大多数公司以某种命令和控制方法开始软件版本发布，这是一种中央智能组织推动和控制工作流程，批量大小为N的发布策略是问题所在。 首先是数学上行不通，像很多问题一样，我们

原因：你如果只有计算机科学CS学历，只能称呼自己是程序员，软件工程师需要工程学历。 众说纷纭：1. 没错，在德国，如果没有上过大学并获得学位，就不能称自己为软件工程师。“工程师”一词在欧洲大部分地区受到严格管制，是否有人称自己为“工程师”受到法律的限制。这就是

本文介绍了fail-fast 原理、它的优点、如何应用它以及我的个人经验。尽管看起来违反直觉，但快速失败会使您的应用程序更加健壮。使用快速失败原则，错误和故障会更快出现，这使得它们更容易修复。如果本文启发您在代码库中应用快速失败原则，您可以立即开始使用它。即使您将该原则应用于单个文件

高弹性组织可以解决诸如构建软件等新问题，它是靠发展解决现有问题，是生成性的，总是创造自己的下一个版本来解决明天将出现的问题。一个有弹性的组织会产生积极的结果，即使某处总是出现问题。就像弹性软件一样。旧的、官僚的组织结构图有很多层次；信息向上流动，决策向下流动。一个弹性的、生成的组织结

Spotify 以开发一种吸引大量关注的工程文化而闻名：一切都围绕着创建“小队squads”；许多产品团队试图效仿它，但很少有人能成功。尽管 Spotify 不再使用产品小队，但该方法可以为其他敏捷产品团队带来好处。在本文结束时，您将对 Spotify Squad 框架有一个清晰的了解，以及

在“铁三角”模型中，有 3 个约束条件：资源Resource：有多少人投入范围Scope：需要完成多少工作时间Time：完成工作的时间它们形成了一个三角形，三角形的面积代表质量。如果您曾经听过人们谈论“遗留代码”

在 Tableau，Tableau Mobile团队约有 30 人，分布在 3 个 Scrum 团队中。我们主要在 Tableau Mobil

通过混沌工程，我们为开发人员和基础设施人员提供了准备实时生产的机会，现在他们将成为经验丰富的玩家，可以毫无顾虑地处理生产错误。这是所有组织都需要采用的未来思维方式，因为我们正在快速发展，每天都有新框架，每个组织都在创建工具以摆脱旧系统，它在扩展性，弹性方面为组织提供了足够的灵活性一方面，它使

Thenewstack这篇文章《高度成熟的软件组织的五个习惯》提供参考：成熟的软件公司组织意味着什么？事实上，成熟度并没有一个明确的定义。但事实证明，成熟的组织——定义为那些已经成功实现 DevOps 转型、经常超越业务目标并且收入同比大幅增长的组织——确实有五个共同的习惯。

自从出现第一个“基础结构即代码”工具以来，人们就意识到对版本进行环境定义的版本控制和自动执行更改是很有意义的。您可以说那些早期的先驱者正在使用Git进行操作。或者，您可以将其称为GitOps。就像敏捷，DevOps或云原生一样，经常有人可能会问：“我们真的需要另一个营销流行语吗？作为