Thoughtworks洞见

研发效能就是团队能持续快速交付价值的能力。目的是交付价值，其研发核心能力在于“响应力”与“稳健性”，同时，响应力这一概念又可以从“流动速率”和“资源速率”两个维度来观察。

就本质业务来讲，其实做的其实是高度同质化业务，很难或者说根本无法构建有效的竞争壁垒，在行业内形成业务垄断。

我们实际上不是对客观世界本身建模，而是对我们所认识到的东西，也就是说客观世界在我们心灵中的映像建模。至于我们所认识到的东西和客观世界（如果有的话）的关系就留给哲学家们讨论吧。

好的日志不仅可以为程序开发提供便利，为故障排除提供最重要的辅助信息，更可以为业务或基础设施提供优化建议或数据统计。

这是一个我们不能忽视的时期，一个彻底重新设计运营模式、全力投入持续变革的机会。如果您已经准备好踏上这个旅程，就从以下三步出发。

软件开发者在刚接触和运用TDD时可能会陷入一些教条主义而走一些弯路，本文通过一个实际业务系统的小案例来探讨TDD应提倡的教条和可以规避的教条，探寻TDD的本真~

作为一名程序员，总有一些时候，会对自己所做的重复性的工作感到厌倦，也会羡慕明星项目做得热火朝天 Star 数蹭蹭上涨。而读代码，则是缓解焦虑的良方。

构建业务和技术的统一语言，关注领域建模的分步协作，让“人和互动”成为建模的主体。

行动者的异质性导致了技术发展的多样性。当我们结合微观与宏观的视角时，技术对于社会的影响便不再是点对点的，而更像是一层层洋葱圈。本文将从三个方面探索技术对于个人以及社会的作用力。

程序员的日常就是要在无数失败中找寻让程序正常运行的那一种组合，成功运行更像是运气与实力的双重作用，这也就有了失败驱动开发（Failure Driven Development）。

广义上的设计已经从实体和非实体的物件设计发展到了复杂适应性系统的设计。这种根本性的演变正在改变设计师的角色，设计也理应需要一套新的价值观和方法实践。

在本篇文章中，你们会与我一起穿越回BFF诞生的历史中，寻找其起源。并一同探索和学习这个在分布式系统中出镜率极高的架构模式。

虽然开发工具早已经从 preprocessor 进化到了 styled component，但在我看来新的工具并没有让我们的样式代码写的更好，只是更快——也可能会让代码坏的更快。工具的繁荣并没有让那些导致代码难以维护的根本问题烟消云散，而是更易让我们对其视而不见。这篇文章旨在回答一个问题：为什么样式代码难以写对，它的陷阱究竟在哪里？

对于处在数字化能力本土化阶段的跨国企业来说，云迁移不应该被简单的定义为一个可以一次性解决的技术问题。不仅仅因为它是长期存在的，也因为它意味着系统所有权的转变以及进而带来的架构的改变。

当我们决定使用Event Sourcing作为架构选择之时，通常我们也会选择DDD去构建得到领域事件。DDD里提到的Event指的是对系统状态产生改变的现实事件，同样我们在Event Sourcing的系统中存储的也是会导致系统状态改变的事件。似乎这两种不同的软件开发思想，对Event的认识有着不谋而合的默契。