软件工程资料汇编

作者背景：从1981年左右到2014年退休，我一直从事软件工程或相关学科的研究。从1984年到2014年，我的所有研究都涉及与英国和整个欧洲的工业界合作。我有幸与来自不同行业和国家的许多人一起工作，我从这些经历中学到了很多东西。

多年来，我们注意到开发具有高性能和高效率的软件是多么困难，以及团队因素在这个等式中是多么重要。有时我们没有意识到，我们并不总是需要最好的语言、技术或任何先进或疯狂的概念来达到最佳效果。相反，我们需要的是在心中保持最佳的组织结构，以便使事情变得简单。

微服务、容器编排等的兴起带来了新的工程挑战。许多组织已经成立了平台工程团队来承担这些责任。 什么是平台工程？平台工程可以让程序员以更简单的方式将软件交付给用户。实际就是运维平台，运维监控平台。平台工程是DevOps和业务程序员

本文作者Jason Shah，曾在Airbnb工作多年，现在他在

在过去的十年中，工程和技术组织已经融合了一套通用的最佳实践来构建和部署云原生应用程序。这些最佳实践包括持续交付、容器化和构建可观察系统。与此同时，云原生组织已经从根本上改变了他们的组织方式，从大型部门（开发、质量保证、运营、发布）转移到较小的独立开发团队。这些应用程序开发团队由两个新

作为一名想要成为 DevOps 工程师的人，肯定想了解什么是 CI/CD 以及我们为什么需要它们？CI/CD 是语言/运行时（例如 Java/OpenJDK、JS/Node、Ruby、Docker 容器中的某些东西）之间的粘合代码，包括交付（取决于您的工件类型，例如 Docker 容

在软件工程方面，我们的愿景是让 BBC 以其工程和内容而闻名。为此，我们必须进一步发展 BBC 作为产品和技术公司的理念。我们的资产中有数百个微服务，所以我们有跨学科团队负责每一个。我们尽最大努力在赋予每个团队权力和确保我们全面进行高度协作之间取得平衡。我们希望 BBC 以其

在这篇博客文章中详细了解团队拓扑的工作原理、好处是什么以及如何利用该方法。 由Matthew Skelton和Manuel Pais设计的 "团队拓扑 "方法，专门解决了许多组织苦苦挣扎的挑战：没有足够快和好地将软件送到客户手中。软件团队往往面临着创造价值的巨大压力。然而，除

团队经常使用版本控制分支进行大规模更改，以便他们可以继续开发功能并修复主线上的错误。但是如果您的代码位于分支上，则它不能被集成的。合并回主线肯定是痛苦的，痛苦的程度取决于你想要做出多大的改变，同时你在主线上做了多少工作。 这意味着推

首先什么是敏捷？它来自哪里？ 我第一次遇到敏捷是在图书馆的工作中。我被雇来帮助一个新的数字学术中心落地，有时与图书馆的软件开发团队合作，建立工具来支持我们的项目。这个团队大约有六名成员，我马上注意到他们做事的方式与非技术人员不同。在会议上，他们不谈

OKR（目标与主要结果法）中最重要的是设立“目标”，但是现在的我怎么知道未来成功是什么样？设立的这个目标又如何具体到足以有启发性，又要不能太具体以致太详细，没有足够开放来激发创造力？ 以时间旅行做比喻：首先，我设定了一个目标：我想在未来的某个时间点实现的东西。

我的公司一直在为log4j的修复而苦恼：巨大的微服务架构意味着数百个应用程序需要更新、重建和重新部署他们的repo。更糟的是，自从log4j之后，该公司对所有的库都进行了严格的扫描和修复要求。如果在几天内没有得到解决，存储库中的镜像有任何CVE，现在就会被升级到有副总裁参与的

OKR是目标和关键结果，这如何应用于产品设计，当你设定目标时，KR是目的还是结果？如果它们是结果，那么你怎么知道你的设计是否对你所测量的结果有所贡献？例如，如果KR是 "在推出仪表盘后销售量增加2%"。如果销售量真的增加了，那就很难仅仅归功于仪表盘的设计。 <

故事点有两个目的： 1：强迫团队讨论并就工单的范围达成一致 2：让产品经理大致了解完成一组工作需要多少个 sprint，以及每个 sprint 可以完成多少工作。 对于利益相关者，甚至不会向他们提及故事点。他们唯一需要知道的是团队估计完成他们想要完成

在我 12 年多的职业生涯中，我帮助雇佣了 100 多名工程师。我管理并指导了多个工程团队的职业生涯。其中一些可能会让您感到惊讶，但我相信它们预示着我们行业的职业成功。 1. 工程师如何处理繁杂的工作工程师

财务和技术债务现在在很大程度上是众所周知的概念，它们在组织中发挥着极其重要的作用。但是存在第三种债务，可能比它的任何一种债务都更有害，任何希望在 21 世纪建立可持续组织的人都需要了解它。去年，创业大师