Thoughtworks洞见

验证软件具备基础的体验能力后，测试人员不妨故意“犯傻”，反向验证一下软件的防呆能力。

在这个时代，有了技术的加持，我们可在小型社区网络中一起工作，而且界限更少，目标也更宏大。

BFF在前后端分离的架构模式下隔离了前端和后端的关注点，特别是在多个前端或第三方的情况下，BFF都是非常好的选择。

很多新手在刚入门原型设计时，总会花费很多精力在工具的选择和打磨上，却忽略了原型设计的核心。等真正上起手来，只能照猫画虎，没有一个完整且系统的思路。因此我想聊一聊我在设计产品原型时的思考过程，希望对新上路的小伙伴们有所帮助。

在Thoughtworks，我们通过对最佳实践(Sensible Default Practices)、能力和度量的持续治理和改进，在保障交付正确的客户价值和减少浪费的基础上，使交付质量更好，速度更快，反馈更及时，从而达到追求工程卓越和形成发展工程师文化的目的，最终产生客户影响力。

基于Cloud Spanner独特的结构，它能确保客户在以较小的用户群和业务量为起点时，不必过多担心在未来数据量和业务量增长后需要对数据库进行迁移或重新编写的问题。

即便是一个五年前就开始转型的组织， 到现在仍然困扰于“业务和IT同床异梦、 PO和BA哪边来出？” 这类的问题。业务和科技融合，到底为什么这么难？

本文提供了一个从落地实施角度观察数据仓库的视角，数据仓库并不是简单的技术组件堆砌，使数据仓库产生价值更需要会“掘金”。

契约测试不是一个新鲜东西，但在实际项目经历中发现用好契约测试真的会大大增强开发的效率，因此写下这篇文章来简单总结一下契约测试的一些内容。

“一切皆流、无物永驻”—- 赫拉克利特

Matthew Skelton和Manuel Pais在他们提出的团队拓扑学中，倡导团队优先的思维方式，以降低团队认知负载为宗旨，避免工作内容（架构、运维等）超出团队的最大认知负载。

在做 DDD 的培训和工作坊时，会遇到来自客户或学员的疑问，有些问题值得我们深入思考。我整理了一些常见的问题，欢迎补充和讨论。结合 DDD 社区最近的讨论成果，这里我先给出一个简单的参考答案。

本文主要通过对产品创新的难题分析、产品工厂的实践模式剖析，深度解读金融机构如何搭建产品工厂体系。

本文从“团队协作的五大障碍”出发，首先对团队协作过程中遇到的各种问题进行抽象归类，然后分享我们在团队中试过且效果很好的一些敏捷实践，最后展示建设成果，最后展示建设成果。

我们正在书写、即将面对、正在面对遗留系统。在与遗留系统的相爱相杀中，需要我们基于项目目标和现状、结合过往经验、经过剪裁和取舍，才能迎面不断出现的挑战。