团队拓扑

     

什么时候应该转向微服务?

139 6K

什么时候仍然选择微服务是正确的?微服务架构是一种将软件拆分成小型独立服务组成的架构,它可以提供更好的扩展性和快速开发能力。微服务需要按照业务功能划分,实现自动化部署和独立部署,还需要具备封装、去中心化.

认知负荷决定了微服务或单体

242 1 4K

这篇文章主要讨论了在软件架构设计中考虑团队认知负荷的重要性。 根据团队的能力和需求,可以选择单体架构或微服务架构。 单个团队适合使用单体架构,多个团队适合使用微服务架构。 文章还介绍了认知负荷的三种类.

什么是探索树工程方法?

57 2K

介绍了一种名为"Discovery Tree探索树"的工作追踪和聚焦技术。它是一种敏捷的工作追踪方式,通过可视化的方式有效地跟踪工作进度和任务状态。这种方法可以帮助团队更好地理解工作,提高效率,并保持.

最佳软件架构书籍终极清单(2024 年)

481 1 6K

这篇文章介绍 2024 年您应该阅读的最佳软件架构书籍列表。1、软件架构基础知识马克·理查兹和尼尔·福特的工程方法本书是一本关于软件架构的综合指南,由经验丰富的从业者撰写。它涵盖了软件架构的各个方面,.

架构决策的制定过程

127 5K
自 20 世纪 90 年代软件架构诞生以来,架构决策 (AD) 一直在回答有关设计选项的“为什么”问题。捕捉它们的方法应该成为每个架构师工具箱的一部分。少即是多——只有关键的广告才能证明这一努力的合理.

如何构建实实在在的能力模型?

99 2K

业务能力是组织规划生态系统的核心。能力映射有多种用途,其中两个至关重要。首先,业务能力有助于更快地确定优先级,首先关注最有利可图的计划。其次,精心设计、扎实的、基于能力的详细路线图可以实现更准确、风险.

CNCF《平台》白皮书

103 3K

本文旨在支持企业领导者、企业架构师和平台团队负责人倡导、调查和规划云计算内部平台。我们认为,平台会对企业的实际价值流产生重大影响,但只是间接影响,因此领导层的共识和支持对于平台团队的长期可持续性和成功.

一句话总结敏捷实践中不同方法

66

敏捷实践是指一组优先考虑灵活性、协作和客户满意度的软件开发和项目管理原则和方法。不同方法论的敏捷实践:1、敏捷: Sprints:限时迭代(通常 2-4 周),在此期间创建潜在的可交付产品增量。 每日.

通过业务架构和IT架构提供价值

87 2K

企业架构需要足够的资源来规划和映射适当的客户驱动的业务架构,但IT架构的3个领域不应被忽视,即应用程序/服务、信息/数据和技术/基础设施。企业架构中的业务架构领域不仅仅涉及业务功能和业务流程。最重要的.

谷歌:编写干净的代码以减少认知负荷

236

您是否曾经阅读过代码却发现很难理解?您可能正在经历认知负荷!认知负荷是指完成一项任务所需的脑力劳动量。阅读代码时,您必须记住变量值、条件逻辑、循环索引、数据结构状态和接口契约等信息。随着代码变得更加复.

如何培养基于数据的产品思维?

89 3K

数据作为战略推动者的作用对于组织的长期竞争力变得越来越重要。例如,Netflix 是成功利用数据来加强和维持其竞争市场地位的组织的杰出例子之一。该公司众多数据驱动的创新之一是其市场领先的推荐系统,该系.

微服务不是问题,无能才是!

267 1 10K

微服务不是问题,认知能力才是关键,无法意识到"认知负荷"存在的人,是无能的人,是组织无能微服务本身并不是问题,对于较小的产品,单体架构也不一定更适合。无能软件工程领域的炒作令人难以置信。微服务是当前的.

两种类型的科技公司

87

本文批评了科技公司的两个极端行为: 第一个只关心可量化的结果,并将技术债务归咎于工程师; 第二种情况是,员工整天花在很少阅读的文档和配置上,而初级工程师则希望使用流行的工具。 虽然两者同样糟糕,但技术.

2023 年价值流管理现状

58

价值流管理联盟最近发布了我们的第三份年度报告《2023 年价值流管理状况》。今年的报告深入探讨了 VSM 采用率如何不断提高以及这些实践如何推动更高水平的组织绩效。2023 年报告的主要发现包括: ■.

Spotify的产品模型

154 6K

Spotify 是一家杰出的公司,是我工作过的最好的公司。六年多后,当我离开公司时,我想帮助其他公司变得更像 Spotify。然而,我不认为公司可以仅仅复制后来被称为“Spotify 模式”的部落、分.

产品工程师和堆栈工程师的区别

91 3K
成为产品工程师后,最大的转变可能就是从用户的角度思考问题。技术上的合理性要让位于用户的需求。当我还是一名堆栈工程师时,我会从 "技术上有哪些可能性?"的角度来处理问题,然后与产品经理协商,选择一个稍微.

有关麦肯锡量化开发人员生产力的错误之处

117 3K

今年八月,咨询巨头麦肯锡在一篇题为“是的,你可以衡量软件开发人员的生产力”的文章中宣布了自己的解决方案,但引起了不同的反应。开发人员的生产力是一个很难定义的概念。为此,麦肯锡选择了两个流行的工程度量框.

戴尔·卡内基《如何赢得朋友并影响他人》总结和要点

129

戴尔·卡内基的Dale Carnegie's 《如何赢得朋友和影响他人》How to Win Friends and Influence People是有史以来最受欢迎和最有影响力的自助书籍之一。该书.

软件架构本是软件工程师的一项职能?

79

在软件行业,似乎普遍认为软件架构和软件工程是截然不同的。在很大程度上,软件架构关注的是设计,而软件工程关注的是实现(即编写代码),两者在某种程度上是相互独立的。从根本上说,两者之间的联系大致类似于建筑.

最差的程序员

413 2K

衡量开发人员工作效率的最大好处是,你可以很快找出那些糟糕的程序员。我想给大家讲讲我认识的最差的程序员,以及我为什么要把他留在团队里。几年前,我在 Twitter/X 上写过一篇关于我认识的最好的程序员.

什么是软件开发中的“两份比萨队”? - martinfowler

310 1

双披萨团队是为特定业务能力提供全面软件支持的小型团队。这个词因用来描述亚马逊如何组织其软件员工而流行起来。这个名称暗示了此类团队最明显的特点,即团队的规模。这个名字来源于这样一个原则,即团队的规模不应.

什么是团队拓扑? - martinfowler

565 1 2K

任何大型软件工作,如大公司的软件产业,都需要大量人员,而只要有大量人员,就必须想办法把他们分成有效的团队。组建以业务能力为中心的团队有助于软件工作对客户的需求做出响应,但所需的各种技能往往让这些团队不.

团队拓扑中的平台团队与产品团队 - martinfowler

323

产品交付团队为公司的客户构建功能 - 他们正在构建的产品的最终用户就是公司的客户。我还看到这些类型的工程团队被称为“功能团队”、“产品团队”或“垂直团队”。在本文中,我将使用“产品团队”作为产品交付团.

Xapo银行去中心化的DDD架构实践分享 - martinfowler

691 9K

Xapo银行使用领域驱动设计、团队拓扑和架构建议流程三种方式实现企业架构的去中心化:软件架构在构建软件系统实践中的作用一直备受争议。在大多数组织中,你会发现某种 "架构 "功能,通常打着 "企业架构 .

团队拓扑:模块化与划分团队相结合

577 9K

Martin Fowler的同事Matthew Foster描述了团队拓扑和领域驱动设计如何帮助组织扩展技术架构和团队结构,从而显着提高开发速度。模块化架构能改善软件交付吗?是的!但要注意一些问题。这.

康威定律:团队结构与软件架构之间的相互作用

519 2K
英国议会下议院在1941年的闪电战中被摧毁后,上议院就如何重建下议院展开辩论。一些人认为这是向马蹄形 "架构 "转变的机会,但丘吉尔团队主张他们保留 "对抗性的长方形架构"。他认为,这种布局本身就是英.

产品经理形象生动介绍什么是敏捷?

349 2K

本文试图以一种简单的方式写下敏捷方法之间的区别:把它写成两个朋友之间使用送餐应用为案例的对话。拉克什Rakesh,一个聪明的、精通技术的开发者,和他的朋友汤姆Tom,一个没有技术背景的人,正在进行一场.

微服务反射和扩展复杂自适应系统 - James Lewis

441 9K

James Lewis是ThoughtWorks的总监,也是微服务架构的先驱者。在这一集里,我们回到了记忆的长河,回到了James第一次提出并普及微服务架构的时候。詹姆斯描述了他对微服务的定义和它的重.

为什么要使用eventSourcing?

616 2K

eventSourcing将事件建立为系统中唯一的事实来源。通过采用动态一致性边界DCB,eventSourcing提供了高度灵活的事件使用,允许随着时间的推移出现最佳的设计。事件流系统事件流系统通常.

设计模式导致了认知负担?

484 3K

在不同的团队中编码多年后,我想我现在终于可以向自己解释,为什么我们需要或不需要用模式和抽象构建的 "聪明的 "代码。最近我一直在阅读关于团队组织的各种方法(尤其是“团队拓扑”)以及如何组织团队以减少认.