Thoughtworks洞见

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

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

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

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

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

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

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

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

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

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

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

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

本文将从服务间上下游的思维来讨论如何在系统架构演进过程中，持续的保持服务间的松耦合，实现解耦的目标。

本文为[从项目制到产品制]系列之6，在上篇融合型机制之后，来谈谈从业务规划到IT落地上线的流程和关键动作。 最 … [阅读更多]

近几年，随着数据和人工智能越来越受关注，数据与人工智能项目（统称数据项目）也遍地开花，和传统应用类项目相比，数据项目有其自身的特点和挑战，本文就来盘一下这些挑战。