仅仅因为某些东西有效，是否就意味着您不必重构？
我刚刚在 WP 代码库中看到了这行代码。
if ( $user_id = wp_validate_auth_cookie( '', apply_filters( 'auth_redirect_scheme', '' ) ) ) {
}
嗯。是的。 if 语句中的两个方法调用和一个赋值语句。
所以，我的猜测是，没有人重构这个。
有什么原因吗？
I just saw this line of code in the WP codebase.
if ( $user_id = wp_validate_auth_cookie( '', apply_filters( 'auth_redirect_scheme', '' ) ) ) {
}
Um. Yeah. two method calls and an assignment statement in an if statement.
So, my guess is, nobody is refactoring this.
Are there any reasons why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
回答你标题中的问题：
如果是这样，我们永远不会重构。因为重构发生在绿色上。也就是说，当所有测试都通过时，根据定义，代码可以工作时，就会发生这种情况。如果你在红色上“重构”，那么你就没有重构。你正在玩你的代码。你正在冒你可能不应该冒的风险。重构是改进现有代码的设计，而不改变其行为。如果您的代码无法正常工作，如果您没有测试来证明其正常工作，那么您所做的更改可能会改变其行为。
To answer the question in your title:
If it did, we'd never refactor. Because refactoring happens on green. That is, it happens when all tests are passing, when - by definition - the code works. If you "refactor" on red, you're not refactoring. You're playing with your code. You're taking risks that you probably shouldn't be taking. Refactoring is improving the design of existing code, without changing its behavior. If your code isn't working, if you don't have tests that demonstrate that it's working, then the changes you make could be changing its behavior.
这肯定打破了一些编码标准，但是它打破了WP编码标准吗？
我不会在 IF 块的条件下进行赋值。人们总是会想，这应该是
==而不是=吗？重构有助于收回一些技术债务。单元测试和良好的代码覆盖率使重构变得更加容易。
一个好的经验法则是，任何时候你接触代码（或者必须盯着它来解读它），那就是重构它的时候，这样下一个人就不必处理它。在这种情况下，你查看了代码，你应该重构它。当然，这些是小组必须同意的指导方针。
理想情况下，您应该控制技术债务。
This is certainly breaking some coding standards, but is it breaking the WP coding standard?
I wouldn't have an assignment in the condition of an IF block. People will always wonder, is that supposed to be
==instead of=?.Refactoring is good to earn back some of your technical debt. Unit tests and good code coverage makes refactoring easier.
A good rule of thumb is any time you touch the code (or have to stare at it to decipher it), that's the time to refactor it, so the next person doesn't have to deal with it. In this case, you looked at the code, you should refactor it. Of course, these are guidelines that the group has to agree on.
Ideally, you should keep your technical debt under control.
时间是一种奢侈，不是每个人都拥有的。我很乐意回去重构我曾经编写过的每一行代码。我们总是在学习（希望如此），并且可能总是可以回去重构我们编写的东西，使其更简洁、更优雅、更高效等等。
但现实是……如果它有效，那就没有了通常优先考虑返回并“修复”它。很可能你正在开发一些新的东西，而客户并不真正关心你在一个代码块中是否有 2 个方法调用，而一个方法调用就可以。他们想要他们的产品。
如果有问题的代码性能太差以至于系统无法使用，他们会让您知道（相信我），此时您肯定会进行重构。
Time is a luxury that not everybody has. I'd -love- to go back and refactor just about every line of code I've ever written. We're always learning (hopefully), and could probably always go back and refactor things we've written to be more concise, more elegant, more performant, etc.
But the reality of it is... if it works, there's not usually a high priority to go back and "fix" it. Chances are you're working on something new, and the client doesn't really care if you've got 2 method calls in a block of code where one will do. They want their product.
If the code in question is so non-performant that the system is unusable, they'll let you know (trust me), at which point you'll definitely be doing the refactoring.