这些天，每个人都在谈论平台工程。甚至 Gartner 最近也在其2022 年软件工程炒作周期中对它进行了介绍。但是平台工程的真正意义是什么？它是DevOps发展的下一个阶段吗？它只是 DevOps 或.

“平台工程”已被提议作为 DevOps 和 SRE 的替代方案。我们已经看到了针对 GPT-3 的类似 SQL 注入的攻击的演示；星巴克、Chipotle 和环球影城等公司正在提供基于 NFT 的忠诚.

在任何有规模的公司中，大多数高级领导人在一个好日子里都会有30分钟到几小时的会议。其范围包括与客户会面、团队审查、经常性的战术会议、1:1会议或技术架构。根据我的经验，你所管理的组织越大，或者你所驾驭.

CI/CD部署管道可以帮助开发软件和组织架构来促进快速流动，从而提高业务敏捷性。任何软件交付工作的核心都应该是部署管道，Jez Humble和Dave Farley在其开创性的 2010 年著作《 持.

关于如何更快地交付软件的讨论在我们的社区中无处不在。围绕着流程和组织结构的讨论有很多，但围绕着提高信任度作为快速流程的促成因素的讨论却不多。今年，我有一些对话和经历，让我真正意识到信任的重要性。特别是.

让我们从基础架构即代码 (IaC) 和配置管理开始：基础设施即代码/配置管理基础架构即代码 (IaC) 允许您自动配置云基础架构。无论是虚拟机、数据库、云网络、安全等，您都可以创建一个包含所有细节的 .

成为软件架构师的典型路径始于多年来亲身参与的软件开发工作。你已经积累了广泛而深入的技术知识。在这个过程中，你已经发展了你的沟通技巧。我并不只是指状态报告。我指的是通过指导初级开发人员，向你的同行介绍你.

有人曾经告诉我，任何类型的团队或组织所经历的最艰难的转变是从大约 30 人增长到 60 人。当时，我记得我在想，“嗯，这很随意。当然，每个组织都是不同的。” 在某些方面，每个组织都是不同的。然而，我见.

随着软件开发的工作变得越来越复杂，现在可能是开发和运营专家再次分开的时候了。但这能做到不重复过去的错误吗？2000年代末，随着敏捷方法论和云计算的兴起，Devops也随之出现，因为软件开始侵蚀世界。D.

敏捷项目已经变成了 2 周冲刺的臃肿、懒惰的瀑布项目。瀑布式生产线方法适用于具有已知需求或制作小部件的项目。敏捷宣言充满热情、活力和可以做的态度。它使小型团队能够在最少的指导下创建软件，并告诉他们去获.

在我的工程生涯中，我做出了一个选择，离开了个人贡献者（IC）的轨道，转而担任技术领导职务。当时，我觉得自己已经在一些工程学科上取得了知识和技术深度，想尝试一下领导力。像很多人一样，我做出这样的选择是出.

让我分享一下我尝试在大中型公司中引入它的经验。有些你会看到的东西听起来很明显，但是这是我的经验，我想和你分享。这些年来我学到的第一件事是：从小处着手！从小事做起这是什么意思？这意味着，根据公司的规模，.

上下文映射，最早是由Eric Evans在领域驱动设计中描述的，是一种轻量级的方法，用来描述系统和系统的一部分之间的关系。它本身不是技术性的。它暴露了组织的政治和构建系统的团队。当你开始绘制时，连接两.

亮点：微服务并不能确保良好的模块化：如果您使用微服务足够多，您可能会构建或借用一些不错的工具来简化服务之间的通信。但是，如果你不小心，你最终会得到一个紧密耦合的微服务式单体，每个函数都有大量的 HTT.

敏捷无处不在。似乎每个人都想成为敏捷。如果你没有敏捷的团队，你就是一个恐龙。但是，一个组织并不是简单地成为敏捷。下面是组织在成为敏捷时犯的十个错误。10. 自上而下的敏捷实施我知道有些组织是自上而下地.

如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读，那就是Mathew Skelton 和 Manuel Pais 的《团队拓扑》。顾名思义，主题是关于组织业务和技术团队以实现快速流动。我想说这.

我们需要转向所有产品和工程团队（不仅仅是共享服务）都发布 API 的模型，这样其他团队就可以从他们正在构建的东西中受益，而无需安排会议。随着公司规模的扩大，他们通常会放慢速度，并变得更有效率。需要更多.

在您的软件开发生涯中开发应用程序可能采用的众多方法之一是API-First Approach。在本文中，我们将深入探讨其核心概念并了解有关此方法的更多信息，我们还将熟悉在此方法中可能需要的一些工具。背.

组件团队：每个团队负责一个系统组件。例如，有一个团队负责前台，一个团队负责后台，还有一个团队负责数据库。这三个团队独立运作，这经常导致团队之间的相互依赖。这些团队不是为最终用户提供价值，而是花了很多时.

情境-行为-影响：Situation-Behavior-Impact简称SBI，不加评判地向他人提供更清晰的反馈。当我们对某人的行为持否定态度时，我们往往会跳出结论，并对某人的行为方式做出假设。在给那.

软件设计与康威定理是两种不同的东西，软件设计是针对软件的，康威定律认为团队组织管理方式决定了软件的设计，因为这两者本身就属于一个大系统。但是虽然你的团队划分按照康威定律，最终软件设计还是不行，原因是康.

Shubhro Saha 是 Facebook 的工程经理。他写了一篇很棒的博客文章，介绍了如何更好地估计一个项目需要多长时间才能完成。一个很好的提示是始终清楚地将估计与目标与计划分开。目标可能是最乐.

2021年初，在Snapcommerce，我们有25名工程师在班组工作。每个小组都有一个工程经理（EM）作为所有项目的负责人和技术负责人（TL），一个产品经理（PM），一个设计师，一个QA团队成员，以.

在你的组织或公司中创造多种文化，例如先驱者、定居者和城市规划者就是具有不同的文化的人群：先驱者是杰出的人他们能够探索以前从未发现的概念，未知的土地。他们向你展示奇迹，但他们经常失败。大概有一半的时间，.