X记录空间你是否曾经和才华横溢的工程师一起开发一个全新的代码库，结果一年后却发现它变成了和你之前的遗留项目一样的“临时修补的考古层”？我知道我经历过，而且不止一次。
我以前通常会把责任归咎于事无巨细的管理和不切实际的截止日期。我确信这些因素确实起了很大作用。但最近的一次谈话让我意识到另一个原因——反馈不及时。或者更准确地说，是反馈请求或给予的时间太晚了。
我想我们很多人都经历过这样的事：有人开始开发一项新功能，他们创建了一个特性分支，然后花了几天时间反复修改。之后，他们提交了一个 PR。成千上万行的代码，大量的差异，让人感到不知所措，然后当你发现设计中存在一个根本性的缺陷时，那种绝望感油然而生。这个缺陷虽然不至于让整个功能失效，但却需要完全重写才能正确实现。
从那以后，只剩下两种选择。而且这两种选择都不好。
首先，你可以指出问题并要求修改。这也被称为“当那种人”。没人愿意被贴上这个标签。而且，当作者极力避免再花一周时间重写时，这往往会导致激烈的争论。
另一种选择是放任不管。你勉强批准了 PR，代码被合并到主干。你知道这以后会出问题，而事实也的确如此。代码库变得更糟，技术债务也增加了。但你不想成为那个惹麻烦的人，也不想和你的经理就 Velocity 项目进行“谈话”。
你或许会认为，如果作者事先征求反馈意见，这种情况就能避免。但他们为什么不这样做呢？是因为他们喜欢这种既成事实的做法吗？很可能不是。事实上，也许他们确实征求过早期反馈意见，只是没有人提供而已。
这种情况也经常发生。有人写了一份解决方案的概要描述，然后……就没人管了。这需要把这份描述转化成更具体的方案。这才是从概要描述中发现问题的方法。这需要付出努力，通常比仅仅浏览一份已经准备好的方案要费力得多。这就形成了一个难以打破的恶性循环：
- 人们不主动寻求早期反馈，因为他们认为不会得到反馈。
- 迟来的反馈不予提供，因为为时已晚。
- 存在设计缺陷的代码会被合并，这并非因为有人恶意或能力不足，而是因为通常情况下，两个人的检查比一个人的检查要好。
我的收获是，应该更频繁地寻求早期反馈。即使我不相信自己会收到反馈，但创造这种可能性或许会在未来有所裨益。同时，我也应该努力督促自己尽可能地提供早期反馈，即使我并不觉得需要付出这样的努力。此外，这样做还能让开发过程更加注重协作而非单方面签字确认，这无疑是件好事。
