ThoughtWorks洞见

引言 在日常项目中，我们常常会遇到线上性能问题，尤其在微服务的场景下，调用链错综复杂，如何才能快速的定位和解决 … [阅读更多]

聚合分组法采用“相关性”来划分限界上下文，其问题在于缺少一个主题，而子域恰好可以用来提供这个主题。本文的“愿景”-“核心域”-“周边子域”方法，不是唯一分解问题域的方法，任何可以将领域分解成高内聚低耦合的子域的方法都是可行的方法。

如何验证，数据是最为恰当的手段之一：有针对性地埋点，对产品进行数据度量，通过定性定量分析，学习数据带来的结果，去伪存真，形成客观认知，进而构建新一轮的迭代增量——以此来践行产品演进，或许再适合不过。

技术是由一万个细节组成的，哪怕一个这么简单的题目，也有如此多的点。我也不敢说自己是什么高手，起码写了许多年代码，也就把自己写代码的思维展示给大家，希望对有心人有所帮助。

如果能发现“要害点”，作为优先改进的点，且有方法来“啃硬骨头”，那么就能让持续改进切中要害，成效更大。

面向C端租户提供低质且廉价的合租式公寓不是一个好的创业机会，无法养育出大体量的平台或公司，更适合包租的模式。

提高缺陷响应力有助于提升软件质量，如果我们不能把Bug扼杀在摇篮里，就尽快干掉它，把它变为一个happy accident吧！

在这1个多月期间，我所在的团队体验了一段美妙的远程工作时光。虽然我们的项目上有着50多位同事，多个小团队并行工作，但是我们的团队依然保证和WFH前的交付速率和质量，也没有为了保证速率而加班。

一个iOS应用最终能在用户的设备上使用，是经过了开发 -> 打包 -> 发布 -> 下载安装 过程的。为了更易于理解，以及避免从一开始就陷入细节，本文将逆序讲述整个过程。

据多年在各家银行推动创新，建立机制的落地经验，我们总结出我国银行创新机制框架IMFB，帮助银行在组织级层面，有的放矢、有章可循、循序渐进地推进创新机制建设，使得整个过程更加合理高效。

从我自己的角度来说，十分推荐采用Flutter。可能web端和desktop端目前还不那么成熟，但是native端可以大胆尝试。

DevOps实现的最终目标是快速交付，整合了精益思想、敏捷思想、学习型组织，它是一套科学的思想和实践方法，实施DevOps才是打破恶性循环，实现价值交付的最好解决方案。

无论B2B还是B2C企业，在探索数字化转型的路上都面临同样的挑战：如何从市场洞察辅助产品研发，缩短产品上市周期，客户对价格透明度要越来越高，渠道管理的困境以及更好的消费者体验。而这些问题的解决，同样离不开几个关键词：建立创新的文化和真正采用数据技术。

商业环境的变革速度和变革规模正以前所未有的态势发展，个人和组织的生命周期都在“缩短”。为了让“客厅的尸体”能够持续触目惊心，时刻提醒我们接下来要走的路，组织必须要快马扬鞭，加快变革速度，在被组织腐蚀之前，在被组织惰性征服之前，快速占领致胜高地，以胜利者的姿态继续迎接下一次变革浪潮。

​技术雷达是ThoughtWorks每半年发布一期的技术趋势报告，它不仅是一份持续的技术成熟度评估，其产生还源于ThoughtWorks另一个更大宏大的使命—IT革命。我们一直深信，IT行业从定位、价值、实践和技术都会发生巨大的变革。然而任何宏观的变革，都会有一些微小的信号，我们需要持续关注这些微小的改变，这也就是技术雷达的由来。