blocks|key|940713|text|我怀疑是否有任何规范。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|940714|对于你的分解:大多数团队不编写单元测试，也不重构(直到某些东西中断或阻碍开发)。最常见的，重构时间分配是<1+%25。|940715|如果你对良好实践感兴趣的话.|940716|作为开发过程的一部分，|940717|重构可能是一个持续的活动。你看到了一个改进的潜力，你亲自分配了一些时间让事情变得更好。在这里，重构时间<5%25。|unordered-list-item|940718|执行常规代码评审。比如说，几个月一次。然后，您可以专门花几天时间让团队只检查他们的代码并对其进行改进。这里也<5%25。|940719|940720|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|J|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I doubt there are any norms.

To your breakdown: most teams do not write unit tests and do not refactor (until something breaks or stalls development). Most commonly, refactoring time allotment is &lt; 1 %.

If you're interested in good practice then....

<ul>
<li>Refactoring may be an ongoing activity as part of the development process. You see an improvement potential and you personally assign some small time to make things better. Here refactoring time &lt; 5%.</li>
<li>You perform regular code reviews. Say, once in a few months. Then you can dedicate a few days exclusively for the team to only review their code and improve it. Here also &lt; 5%.</li>
</ul>

blocks|key|426407|text|这取决于许多因素，如您所处的业务类型、您的公司使用的流程类型、您所在的团队类型、您使用的语言等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|426408|他们绝对不是正确的答案。如果您所处的领域在需求中移动了很多，并且客户端更改了很多，并且使用了敏捷方法，那么您将更容易进行重构。如果您在一个银行，并且您有一个使用级联方法的团队，那么您更容易编写越来越少的重构代码。|426409|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

This is depending of many factors like the type of business you are in, the type of process your company use, the type of team you are in, what language you are using, etc.

They are absolutely no right answer. If you are in a field that is moving a lot in the requirement and if the client change a lot and you use an agile method you will be more susceptible of refactoring. If you are in a Bank and you have a team that use a cascade approach you are more prone to write code more and less refactoring.

blocks|key|905088|text|我的重构方法是在修复事物的同时进行重构。重构的好处只有在维护代码时才能实现，所以重构代码没有什么好处，因为它没有太多的bug，也不需要任何新的特性。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|905089|无论何时修复bug，我都会寻找重构的方法，即重构时间包含在编写代码/调试类别中(我认为这是两个不同的类别)。|905090|entityMap^0|K|C|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

My approach to refactoring is to do it at the same time as fixing things. The benefits of refactoring only ever come when maintaining code, and so there is very little benefit to refactoring code which doesnt have many bugs and doesnt require any new features.

Whenever I'm fixing a bug I look for ways to refactor then, i.e. refactoring time is included in the writing code / debugging category (which I would argue is two separate categories).

blocks|key|905542|text|我并没有为诸如重构、单元测试和文档之类的事情指定单独的时间。我只是认为他们是成品的一部分，而这项工作直到他们完成。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|905543|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I don't really designate a separate amount of time for things like refactoring, unit testing, and documentation. I just consider them to be a part of the finished product, and the job's not done until they are.

blocks|key|905642|text|你的设计方法是什么？瀑布？敏捷？你的项目有多大？你的队伍有多大？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|905643|我在做敏捷开发的过程中效率最高的是33/33/33，甚至可能是30/30/40。一旦您编写了测试，然后编写了代码以通过测试，那么您就可以重构并完善代码，确信您没有破坏任何东西。|905644|在一个小项目上，您可以假设完美地架构您的代码，而不必测试/重构(我从未见过这实际上是有效的)。在一个大型项目中，或者在一个有很多人手的项目中，或者在一个有许多客户要求很多不同事情的项目中，重构和测试要比代码本身重要得多。|905645|这就像问，在一所房子的整个生命周期里，你应该建造房屋很多次，你应该查阅多少次建筑规范，以及你应该进行多少次维护。显然，建造房子是最重要的事情，理论上，你可以设计一个“完美”的房子，这将不需要重新装修，但这是不可能的。|905646|你更有可能花一两年的时间来建造房子，而房子的其余部分则会定期翻新。加强承载成员比建造一个甲板更重要，即使你的客户要求一个甲板。他们会不高兴，但如果屋顶倒塌，他们只需要住在甲板上，他们就会更不开心。|905647|同样，您将花费X倍的时间编写代码，但是在整个项目的生命周期中重构和优化代码的时间更长。|905648|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

What is your design approach? Waterfall? Agile? How big is your project? How big is your team?

The most productive I've been while doing Agile development tends towards 33/33/33, or maybe even 30/30/40. Once you've written the test, and then written the code to pass the test, then you can refactor and hone the code, confident that you're not breaking anything.

On a small project, you can hypothetically architect your code perfectly and never have to test/refactor (I've never seen this actually work). In a large project, or one with many hands in it, or one with many customers asking for many different things, refactoring and tests are far more important than the code itself.

It's like asking, over the lifetime of a house, haw many times you should build the house, how many times you should consult the building code, and how many times you should perform maintenance. Obviously building the house is the most important thing, and in theory, you can architect a 'perfect' house that will require no renovation down the line, but it's unlikely.

You will more likely spend a year or two building the house, and the rest of the house's duration periodically renovating. Reinforcing the load-bearing members is more important than building a deck, even if your clients are asking for a deck. They'll be unhappy, but they'll be even more unhappy if the roof falls in and all they have to live on is a deck.

Likewise, you'd spend X amount of time writing the code, but a larger amount of the time refactoring and optimizing it through the lifecycle of the project.

blocks|key|941253|text|首先，编写代码/调试/重构是IMO在整个项目生命周期中应该发生的一项独特活动。完美的设计并不存在，因为设计只是昙花一现。今天完美的东西可能会因为明天的新需求而完全失效。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|941254|第二点，我已经看到许多项目，编写单元测试比编写代码要花费更多的时间来使它们通过。|941255|所以对我来说，比率更像是：|941256|941257|50%25：单元测试|unordered-list-item|941258|941259|剩下的是coding/debugging/refactoring/documentation：|941260|941261|941262|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|U|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|-4|5|I|7|X|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|P|$]]

First point, writing code/debugging/refactoring is IMO a unique activity that should occur during all the project's life. A perfect design doesn't really exist as a design is something ephemeral. Something perfect today can be totally invalidated by new requirements tomorrow.

Second point, I've seen many projects where writing unit tests takes more time than writing code to make them pass. 

So to me, ratios are more like:

<ul>
<li><blockquote>
 50%: unit tests
</blockquote></li>
<li>the rest: coding/debugging/refactoring/documentation</li>
</ul>

blocks|key|905817|text|对于好的，精心设计的代码，5%25或更少的声音听起来对我来说，正在进行的开发。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|905818|对于需要认真重新设计的有问题的代码，在添加新特性或修复严重的bug之前，您可能必须为预先重构编制更高比例的预算。|905819|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

For good, well designed code, 5% or less sounds about right to me for ongoing development.

For problematic code that needs serious redesign, you might have to budget a much higher percentage for up-front refactoring, before adding new features or fixing serious bugs.

blocks|key|431272|text|您的评论说，您有数百万行代码，但没有单元测试，而且您很难说服管理层单元测试是值得的。根据福勒的书，重构需要伴随单元测试，以提供信心，你没有破坏任何东西，而你重构。我同意，并且我建议在这个阶段单元测试将提供比其他任何东西更多的价值，所以首先要实现这个目标。我强烈推荐迈克尔·羽毛的“与遗产代码有效合作”一书，就如何做到这一点提出建议。您甚至不需要编写几个以上的单元测试就可以让它成为值得的工作，只需运行框架即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|431273|步骤0:将自动化的单元测试框架应用到代码中。|431274|你不会想独自完成这件事吧？这是一个大项目，我希望你是一个高级技术团队的一部分，与你分担痛苦。你需要让他们全部买下这100%25的东西。当你去找你的老板时，你需要他们的支持，你需要他们的专业知识来分享你的设计，你也需要他们在设计上达成一致。|431275|第一步:召集一群人。|431276|如果没有计划和目标，重构就不会有多大帮助。你是想把代码切成碎片，让模块变小吗？你要把代码组织成域吗？你会尝试将一些服务接口插入其中吗？你打算重构成n层体系结构吗？你和其他人认为需要做什么？你打算如何将这个设计和重构计划传达给SE？|431277|第二步:让团队对最终状态进行一些初步的架构设计和规划。|431278|现在是最困难的部分。你要求的是30名工程师的20%25的时间，每年可能超过50万美元。你需要比“积累的技术债务”更多的理由。你需要展示投资回报。|431279|所以，准备好回答你老板肯定会问的问题：“我为什么要问你？”你期望通过重构得到什么？你会把新特性的开发工作减少10%25吗?+100%25？您会提高代码质量/减少bug/降低支持成本吗？你能加快上市时间吗？多少钱？这会让你减少SE或承包商的人数吗？多少?或者你能在每个版本中增加更多的功能吗？还有一些负面因素:如果给你一年的时间进行重构，有多少特性会被延迟？再推迟多长时间？|431280|第三步:做一些严肃的评估。|431281|所以，既然你已经拥有了一个设计，一个计划，一个经济理由，并且你得到了技术人员的支持，回到你的老板面前，向他或她陈述你的观点。你会有一个更好的运气，比说“我们应该花20%25的时间重构，一些人在互联网上这样说。”|431282|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

Your comment says that you have millions of lines of code but no unit tests, and that you are having a hard time convincing management that unit tests are worth it. According to Fowler's book, refactoring needs to be accompanied by unit tests to provide the confidence that you're not breaking anything while you refactor. I would agree, and I'd suggest that unit tests are going to provide more value than anything else at this stage, so aim first for that goal. I strongly recommend Michael Feathers' book "Working Effectively with Legacy Code" for suggestions as to how to do this. You don't even have to write more than a few unit tests to make it a worthwhile effort, just get the framework running.

Step 0: get an automated unit testing framework harnessed into your code. 

You're not going to try to accomplish this alone, are you? This is a big project, and I expect you are part of a senior technical team who shares the pain with you. You need to get all of them to buy into this 100%. You'll need their backing when you go to your boss, you'll need their expertise to share in creating the design, and you'll need their total agreement on the design.

Step 1: gather a posse.

Without a plan and a goal, refactoring isn't going to help much. Are you hoping to just to chop the code up and make modules smaller? Are you going to get code organized into domains? Are you going to try to wedge some service interfaces into it? Are you going to refactor to an n-tier architecture? What do you and the posse think needs doing? And how are you going to communicate this design and refactoring plan to the SEs?

Step 2: get the posse to do some initial architectural design and planning of the end state.

Now for the hard part. You're asking for 20% of 30 engineers' time, which is probably over $500,000 per year. You're going to need a lot more justification than "accumulated technical debt." You're going to need to show return on investment.

So be ready to answer the question your boss is certain to ask: "why should I?" What are you expecting to gain by refactoring? Will you reduce development effort on new features by 10%? 100%? Will you increase code quality/reduce bugs/reduce support costs? Will you speed up time-to-market? By how much? Will this let you reduce SE or contractor headcount? How many? Or will you be able to add more features per release? There are also negatives: how many features will be delayed if you are given a year to monkey around with refactoring? By how long will they be delayed?

Step 3: do some serious estimating. 

So now that you're armed with a design, a plan, monetary justification, and you have the backing of the technical staff, go back to your boss and present your case to him or her. You'll have a lot better luck than saying "we should spend 20% of our time refactoring, some guys on the internet said so."

blocks|key|941370|text|如果您很难理解您的代码，那么是时候重构.了|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|941371|否则，您可能会因为对代码所做的误解而浪费时间调试；换句话说，您已经承担了太多的债务而不需要进行重构。|941372|类似地，如果您不确定一段代码是做什么的，请确保编写一个单元测试来验证您的理解.。|941373|这些只是我遵循的经验法则，这样我就不会在调试器上浪费太多时间。因此，我花在重构上的实际时间实际上有很大差异，这取决于代码的复杂性和我所处的开发阶段。此外，如果代码过于复杂，这通常表明类必须被分解成更小、更容易理解和更易于维护的部分。|941374|entityMap^0|0|K|0|0|0|13|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|U|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|M|$]]

If you have a difficult time understanding your code, then it's time to refactor.

Otherwise, you risk wasting time debugging due to misunderstandings of what your code does; in other words, you have incurred too much debt to risk not refactoring.

Similarly, if you are unsure what a piece of code does, make sure you write a unit test that verifies your understanding.

These are just rules of thumb that I follow so that I don't waste too much time in the debugger. So the actual time that I spend refactoring actually varies greatly depending on the complexity of the code and what stage I am in development. Furthermore, if the code is overly complex, that's usually a sign that classes have to be broken into smaller, easier-to-understand and easier-to-maintain pieces.

I'm trying to build a plan on how we could spend more time refactoring. So I wanted to compare with the industry standards but I have hard time to find studies or metrics on that.

I feel that 20% of dev time spent on refactoring seems a good ratio, but I don't have anything to show for it.

In my mind, for 100% or dev time:

<ul>
<li>50% is spent writing code, debugging, etc...</li>
<li>30% is spent writing unit-tests</li>
<li>20% is spent refactoring code</li>
</ul>

So around 1 line of code for 2 written end up being in the shipped product.
Obviously design time, documentation time, etc is integrated in these percentages.

What is an industry standard? As a rule of thumb, what is your team using?
Thanks,
Olivier

What is a good ratio of refactoring time versus development time?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正试图制定一个计划，说明我们如何花更多的时间进行重构。因此，我想与行业标准进行比较，但我很难找到关于这方面的研究或指标。我觉得20%的开发时间花在重构上似乎是个不错的比例，但我没有什么可展示的。在我看来，100%或开发时间：50%用于编写代码、调试等30%用于编写单元测试20%用于重构代码因此，大约有1行代码用于编写...

问重构时间与开发时间的好比率是多少？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问重构时间与开发时间的好比率是多少？EN