代码年龄与召回时间

Tim的博客我的一位同事反复呼吁重构我们项目中的某些控制器。他说他们很乱，但我认为他的意思是他们很难理解。乍一看，它们看起来确实很复杂，但是经过仔细检查：

我明白了为什么我的同事会这样看代码。它确实有多个问题，但是在两年的过程中，这种方式反复出现。它所做的所有事情都与先前定义的要求有关，即，它执行了应做的事情。几个月来我们也没有进行任何更改，因为它没有引起任何错误，也没有任何主要的性能瓶颈。

开发人员普遍的偏见是旧代码是不好的。您从未听过有人说过“旧版代码”毫不轻视他们的语气。我很欣赏有时旧的代码不符合团队同意的新方法。例如，旧版PHP代码可能使用现已不推荐使用的PSR-2标准，但是技术负责人可能希望每个人都编写PSR-12。但这是否真的足以危害某项正常工作的功能呢？

我认为经常以这种方式查看旧代码的原因是，记住它需要更长的时间。开发人员渴望清晰，但是如果他们不能立即回忆起在什么情况下（几秒钟或更短的时间）编写了某些代码，他们只会发现模棱两可。

即使在谈论代码时，当我们能够快速回顾以前的对话/决定/动机时，我们也可以放心地谈论它，并向其他人传达我们对它的理解。不幸的是，“我需要五到十分钟来刷新我对此的记忆”无法传达出同样的自信感。 （总是准备。）

减少此＆＃34;召回时间的部分解决方案是通过更好的内部文档，最好是在代码旁边。我们使用了Codestream之类的工具，但我承认并非所有上下文都已捕获。我认为，好的老式评论效果最好。我试图像编号的指令集一样写我的。当然，您也可以使用git注释传达含义。

解决方案的另一部分是作为团队达成共识，在什么情况下应重构代码。如果您的团队共同同意，应该重构稳定，文档完善的代码，请运行。

我是英国伯恩茅斯的软件开发人员Tim White。 当不考虑我的最新项目时，我喜欢做饭，跑步和做饭。 读。