您如何决定接下来要合并/重构代码的哪些部分？
您是否使用任何指标来决定接下来应合并或重构代码的哪些部分（类、模块、库）？
Do you use any metrics to make a decision which parts of the code (classes, modules, libraries) shall be consolidated or refactored next?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不使用任何可以自动计算的指标。
我使用 代码味道 和类似的启发式方法来检测不良代码，然后我将其修复为我一注意到它。 我没有任何用于查找问题的清单 - 主要是直觉“这段代码看起来很混乱”，然后推理为什么它很混乱并找出解决方案。 简单的重构（例如为变量提供更具描述性的名称或提取方法）只需几秒钟。 更密集的重构，例如提取类，可能需要长达一两个小时（在这种情况下，我可能会留下 TODO 注释并稍后重构）。
我使用的一个重要启发是单一职责原则。 它使班级具有良好的凝聚力。 在某些情况下，我使用类的代码行大小作为启发式，以便更仔细地查看类是否具有多个职责。 在我的当前项目中，我注意到在编写Java时，大多数类都会少于100行很长，而且往往当大小接近 200 行时，类会做许多不相关的事情，并且可以将其拆分，以便获得更集中、有凝聚力的类。
I don't use any metrics which can be calculated automatically.
I use code smells and similar heuristics to detect bad code, and then I'll fix it as soon as I have noticed it. I don't have any checklist for looking problems - mostly it's a gut feeling that "this code looks messy" and then reasoning that why it is messy and figuring out a solution. Simple refactorings like giving a more descriptive name to a variable or extracting a method take only a few seconds. More intensive refactorings, such as extracting a class, might take up to a an hour or two (in which case I might leave a TODO comment and refactor it later).
One important heuristic that I use is Single Responsibility Principle. It makes the classes nicely cohesive. In some cases I use the size of the class in lines of code as a heuristic for looking more carefully, whether a class has multiple responsibilities. In my current project I've noticed that when writing Java, most of the classes will be less than 100 lines long, and often when the size approaches 200 lines, the class does many unrelated things and it is possible to split it up, so as to get more focused cohesive classes.
每次我需要添加新功能时，我都会搜索执行类似操作的现有代码。 一旦找到这样的代码，我就会考虑重构它以解决原始任务和新任务。 当然，我不会每次都决定重构——大多数情况下我会按原样重用代码。
Each time I need to add new functionality I search for already existing code that does something similar. Once I find such code I think of refactoring it to solve both the original task and the new one. Surely I don't decide to refactor each time - most often I reuse the code as it is.
我通常只“按需”重构，即如果我发现代码存在具体的、直接的问题。
通常，当我需要实现新功能或修复错误时，我发现当前的代码结构使这变得很困难，例如：
然后我将重构。
有时我会看到看起来有问题的代码，我想更改它们，但如果当前尚未处理该区域，我会抵制这种冲动。
我认为重构是面向未来的代码和做那些不会真正产生任何直接价值的事情之间的平衡。 因此，除非我看到具体的需求，否则我通常不会重构。
我想听听那些经常进行重构的人的经验。 如何阻止自己过度打磨而浪费时间来处理重要的功能？
I generally only refactor "on-demand", i.e. if I see a concrete, immediate problem with the code.
Often when I need to implement a new feature or fix a bug, I find that the current structure of the code makes this difficult, such as:
Then I will refactor.
I sometimes see code that seems problematic and which I'd like to change, but I resist the urge if the area is not currently being worked on.
I see refactoring as a balance between future-proofing the code, and doing things which do not really generate any immediate value. Therefore I would not normally refactor unless I see a concrete need.
I'd like to hear about experiences from people who refactor as a matter of routine. How do you stop yourself from polishing so much you lose time for important features?
我们使用 Cyclomatic_complexity 来标识接下来需要重构的代码。
We use Cyclomatic_complexity to identify the code that needs to be refactored next.
当复杂性指标超过 8.0 左右时，我使用 源监视器 并定期重构方法。
I use Source Monitor and routinely refactor methods when the complexity metric goes aboove around 8.0.