热点开发商生产力。
建筑（30）， 生产力（3）去年年底我喝了咖啡基思亚当斯，我们最终聊了一群迁移在制作它的背景下更容易扩展一个不守规矩的代码库。讨论进入了一堆方向，包括聊聊一下建设进化建筑。一个想法，基特在那个讨论中提到的讨论尤其困扰着我：大多数变化发生在相同的文件中，这些文件是投资质量改进的最有效的地方。
我相信基思将这个想法归功于亚当顿希尔s软件设计X射线，亚当指的是它作为热点。该建议是，代码质量应该相同的方式接近绩效优化问题：测量该附近的更改和优先顺序的优先顺序。这侧重于文件尤其非常棒，因为它捕获了几大类变化，这会极大地影响开发生产力，但在依赖于依赖的时候很容易错过需要更深入地了解软件的工具：配置更改和测试。
这个看似明显的想法实际上与我所学到的关于制作大型软件更改的内容发生了冲突，这是努力降低复杂性的努力通常会在他们正在进行中提高复杂性。更糟糕的是，如果在完成前停止，他们将永久增加填写，而不完全恢复。
这提出了核心问题：我们应该什么时候工作热点，我们应该什么时候努力完成？
你应该优先考虑热点什么时候：
- 你可以衡量影响，而不是进步。例子：时间达到最后一个字节
- 对您的用户有直接，可衡量的影响。例子：错误率，转换率
- 没有终点线或终点线是2多年。例子：“Codebase中没有错误”
你应该专注于完成什么时候：
- 当工作完成时，逐步减小开销或成本，通常从完全弃用现有解决方案。例子：弃用昂贵或缓慢的数据管道
- 分裂方法大大增加了团队心理模型的复杂性。例子：使用不同的故障语义具有三个HTTP客户端库，横跨CodeBase
- 由瞬态项目团队而不是长期所有者的人员。例子：形成“虎队”以迁移失败的数据存储方法
虽然对我来说，这是一个大的外带，而不是一个策略占主导地位，最有助于考虑到两种选择并做出故意选择。