康威定理

     

工程师与知识流失的斗争

69 4K

这篇文章主要讨论了在公司中知识流失的问题,特别是从工程师的角度出发。作者提出了“生物数据存储”这个术语,强调了每位员工在保存和传递知识方面的关键作用。文章指出,知识流失可能会对组织的沟通结构和系统设计.

单体应用、微服务和无服务器

70

本文说明在决定单体、微服务和无服务器架构时权衡的简化思维模型。目标是突出每种风格的固有优势和差距,同时为何时选择哪种建筑风格提供指导。单体小型团队或项目的理想入门架构。它启动起来很简单,并且通常可以提.

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

261 1 4K

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

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

103 2K

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

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

88 2K

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

软件工程:领导力与价值感

555 3K

领导力是最大的推动力,但也可能是最大的障碍。要使变革取得成功,我们需要最大限度地激励员工,最大限度地减少对员工的威胁。乔纳森·斯马特(Jonathan Smart)和西蒙·罗勒(Simon Rohre.

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

323 1

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

什么是团队拓扑? - martinfowler

573 1 2K

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

如何区分微服务还是分布式单体?

556 3K

在没有意识到的情况下,基于微服务的应用可以轻而易举地转变为一个分布式单体。当你意识到这一点时,可能已经太晚了,而且纠正它可能非常昂贵。所以,就像你勤奋地审查代码和架构以确保它们遵守最好的实践、模式和原.

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

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

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

453 9K

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

软件不只是代码,还有程序员头脑中的人和理论

442 9K

Margaret-Anne (Peggy) Storey和Abi Noda是最近发表的ACM论文 "DevEx: What Actually Drives Productivity "的合著者。在这一.

单体炒作很愚蠢 - Darren

485 2

越来越多吹捧单体的炒作如同当初炒作微服务一样愚蠢。当我开始从事技术工作时,世界被GoF四人帮设计模式所困扰。现在,我们被服务架构SOA所迷惑。这些模式往往是陷阱,掩盖了真正的实践经验。你应该从微服务中.

领域驱动设计:做正确的事

1220 1 3K

任何给定软件项目的成功都可以归结为一个相当简单的定义或规则:我们需要构建正确的东西,我们需要正确构建这个东西。这是一个非常抽象和简单的定义,即使不是原始的定义。然而,这是一个很难争论的问题。做正确的事.

逆康威策略在现有系统行不通!

576 2K

逆康威策略不太可能在特定规模和稳定性的现有社会技术系统中发挥作用。在远程公司和分布式团队中工作的可能性更小。简而言之,在现有的社会技术系统中,逆康威机动的执行具有挑战性,而且不太可能产生预期的结果。逆.

我对“Spotify 模式”的批判思考 - Yip

930 4K

虽然我在 Spotify 工作了大约 8 年,但我并不熟悉每个领域的运作方式,而且我有自己的偏见、偏好等。而且情况会发生变化敏捷 > ScrumSpotify 早期主要采用 Scrum(在我的时间之前.

什么是舍基Shirky原则?

1394

舍基原则(Shirky Principle):复杂的解决方案(如公司或行业)会变得太过于专注于他们所解决的问题,以至于他们往往在无意中延续了这个问题。"机构总是试图维护他们所解决的问题。"- 克莱-舍.

Leah的增长和组织扩展指南

794 2K

让我们帮助您开始发展和扩展您的组织。本指南面向创始人、PM 和高级领导者(CTO/CPO/CRO/CMO)。什么是增长?增长是围绕用户获取的功能,也是保留和货币化的功能。追求客户成功是产品和营销的逻辑.

您需要模块,而不是微服务

2007 3 12K

架构有时很难——人们不断提出一些新想法,这些想法很快成为主流的“做事方式”,微服务是最新的趋势,现在是我们剖析这个想法并找到正在发生的事情的真正根源的时候了。在微服务的核心,我们被告知我们会发现……..

Mel Conway:同理心和系统思维

1080

为什么深具同理心共情的人性(情商)和系统思维(智商)很难在同一个人身上共存?我把这部分归因于教育系统:文理分科造成的两种文化:科学和人文科学已经分裂为“两种文化”,这种分裂是解决世界问题的主要障碍。“.

《人月神话》作者弗雷德里克·布鲁克斯去世

1343 1

来自“UNC计算机科学”的不幸消息——Fred P. Brooks,该系的创始人和长期主席几小时前去世了。网友:1、20世纪60年代,布鲁克斯在IBM管理System/360和OS/360项目,这是大.

DDD实施的一些特定总结 - Thomas

959

1、有效的软件是与业务挑战相一致的软件我们所说的一致,是指软件从领域中借用正确的术语,正确阐述业务的关键概念,并尽可能少地避免技术问题带来的意外的复杂性。2、康威定律不是一个可以选择不接受的选项。它的.

康威定律 - martinfowler

1645 1 2K

领域驱动设计在康威定律中发挥作用,帮助定义组织结构:    因为 DDD 的一个关键部分是识别BC:BoundedContexts。    BC一个关键特征是它有自己的UL:UbiquitousLan.

用CAP定理解释成长型组织的大难题 - Nir

1669 1 2K

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

如何在您的公司中引入领域驱动设计? - Fabrizio

1411 1 3K

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

什么时候微服务是一个坏主意? - semaphoreci

1493 1 7K
微服务听起来很棒,它们是模块化的、可扩展的和容错的。很多公司都使用这种模型取得了巨大的成功,因此微服务可能自然会成为卓越的架构和启动新应用程序的最佳方式。然而,大多数在微服务方面取得成功的公司并不是从.

你不需要微服务? - itnext

1985 1 5K

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

团队拓扑:为快速流动而组织你的团队

1499

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

团队如何组织?前后端团队与业务功能团队的比较

3638 1

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

为什么“敏捷”会浪费这么多时间? - Reddit

1027

阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿,两个小时左右的完善和回顾(我曾在一个地方有四个小时的完善),那简直就是把一天的冲刺时间浪费在了会议上。如果团队中.