As a manager, I'm open to code refactoring/rewriting for one of three concrete business cases: reducing technical support, adding new functionality, and improving security.
As a developer, I see two additional "close by" cases where I'll refactor/pay down debt. You might find that your manager is open to these or he may just give you "that look" that tells you he doesn't quite buy it.
First, it sometimes makes sense to refactor simply to improve your ability to add new functionality. For example, if you can see business on the horizon that will require your system to be more flexible and adaptable, then you may need to rethink some of your original architecture's commitments. This is a great time to pay down debt.
Second, when new code is being written that is related to a component that already exists then it makes sense to pay down some debt. For example, if you were adding a new class that is logically a brother class of an existing one, then refactoring out common code into a parent class makes sense. As you do this, you have a great opportunity to pay down debt as well.
根据您所写的内容以及您的项目仍在开发中的事实，我提醒您记住这句格言：“更好是完成的敌人”。 （我相信它是由 Michael Lopp 创造的或至少是由 Michael Lopp 推广的。）在项目生命周期中可能存在重构代码的更好时机。
The answer, as always, is "Show me the money", e.g - show a business case for your proposed solution. Traditionally this would be done by counting service tasks or help desk tickets related to the substandard code. Your specific case will be difficult because it seems you're speaking of an project not in production.
Just based on what you've written and the fact that your project is still under development, I would caution you to remember the adage "Better is the enemy of done." (I believe it was coined or at least popularized by Michael Lopp.) There might be a better time in the Project life cycle to refactor code.
If management are sympathetic, but they balk at giving you 2-3 weeks to do a complete overhaul, then a compromise would be when you're fixing bugs in those components, write some tests and do some limited refactoring, and over time improve the code.
You could just do it, or you could ask that 10% be added to estimates of bugs/features in those areas to be used for that purpose.
The main article from your link has the perfect answer already. This description of technical debt is very good:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
If the project is going to go anywhere the project's manager has to care about it to begin with. If he cares about his project, that description alone should be enough to open his eyes to the idea he probably never thought of. Just help him set up a way to manage noting all the places in your codebase where things need to be improved. Maybe a group or parent ticket in your issue tracking system. That way you can have accountability and a list of what needs to be improved.
In my humble opinion, paying off on your technical debt is something you should do in small bits every time you submit code, not taking time off to do two or three weeks a year.
Continuous improvement in small chunks will work wonders in the end.
发布评论
评论（5）
作为一名经理，我愿意针对以下三个具体业务案例之一进行代码重构/重写：减少技术支持、添加新功能和提高安全性。
作为一名开发人员，我看到另外两个“附近”的案例，我将在其中重构/偿还债务。 你可能会发现你的经理对这些持开放态度，或者他可能只是给你“那种表情”，告诉你他不太买账。
首先，有时为了提高添加新功能的能力而进行重构是有意义的。 例如，如果您看到即将出现的业务需要您的系统更加灵活和适应性更强，那么您可能需要重新考虑一些原始架构的承诺。 这是偿还债务的好时机。
其次，当编写与已存在的组件相关的新代码时，偿还一些债务是有意义的。 例如，如果您添加的新类在逻辑上是现有类的兄弟类，那么将公共代码重构到父类中是有意义的。 当您这样做时，您也有很好的机会偿还债务。
As a manager, I'm open to code refactoring/rewriting for one of three concrete business cases: reducing technical support, adding new functionality, and improving security.
As a developer, I see two additional "close by" cases where I'll refactor/pay down debt. You might find that your manager is open to these or he may just give you "that look" that tells you he doesn't quite buy it.
First, it sometimes makes sense to refactor simply to improve your ability to add new functionality. For example, if you can see business on the horizon that will require your system to be more flexible and adaptable, then you may need to rethink some of your original architecture's commitments. This is a great time to pay down debt.
Second, when new code is being written that is related to a component that already exists then it makes sense to pay down some debt. For example, if you were adding a new class that is logically a brother class of an existing one, then refactoring out common code into a parent class makes sense. As you do this, you have a great opportunity to pay down debt as well.
与往常一样，答案是“给我展示资金”，例如 - 展示您提出的解决方案的业务案例。 传统上，这是通过计算与不合格代码相关的服务任务或帮助台票证来完成的。 您的具体案例会很困难，因为您似乎正在谈论一个未投入生产的项目。
根据您所写的内容以及您的项目仍在开发中的事实，我提醒您记住这句格言：“更好是完成的敌人”。 （我相信它是由 Michael Lopp 创造的或至少是由 Michael Lopp 推广的。）在项目生命周期中可能存在重构代码的更好时机。
The answer, as always, is "Show me the money", e.g - show a business case for your proposed solution. Traditionally this would be done by counting service tasks or help desk tickets related to the substandard code. Your specific case will be difficult because it seems you're speaking of an project not in production.
Just based on what you've written and the fact that your project is still under development, I would caution you to remember the adage "Better is the enemy of done." (I believe it was coined or at least popularized by Michael Lopp.) There might be a better time in the Project life cycle to refactor code.
如果管理层表示同情，但他们不愿意给你 2-3 周的时间来进行彻底检修，那么妥协的办法就是你修复这些组件中的错误，编写一些测试并进行一些有限的重构，并随着时间的推移改进代码。
您可以直接这样做，或者您可以要求将 10% 添加到用于该目的的这些领域的错误/功能的估计中。
If management are sympathetic, but they balk at giving you 2-3 weeks to do a complete overhaul, then a compromise would be when you're fixing bugs in those components, write some tests and do some limited refactoring, and over time improve the code.
You could just do it, or you could ask that 10% be added to estimates of bugs/features in those areas to be used for that purpose.
您链接中的主要文章已经有了完美的答案。 对于技术债务的描述非常好：
如果项目要去任何地方，项目经理必须首先关心它。 如果他关心他的项目，那么仅这个描述就足以让他看到他可能从未想到过的想法。 只需帮助他建立一种方法来管理记录代码库中需要改进的所有地方即可。 也许是您的问题跟踪系统中的团体或家长票证。 这样你就可以承担责任并列出需要改进的地方。
The main article from your link has the perfect answer already. This description of technical debt is very good:
If the project is going to go anywhere the project's manager has to care about it to begin with. If he cares about his project, that description alone should be enough to open his eyes to the idea he probably never thought of. Just help him set up a way to manage noting all the places in your codebase where things need to be improved. Maybe a group or parent ticket in your issue tracking system. That way you can have accountability and a list of what needs to be improved.
以我的拙见，偿还技术债务是您每次提交代码时都应该做的事情，而不是每年抽出两到三周的时间。
小块的持续改进最终会创造奇迹。
那就不需要征求许可了。 :-)
/罗杰
In my humble opinion, paying off on your technical debt is something you should do in small bits every time you submit code, not taking time off to do two or three weeks a year.
Continuous improvement in small chunks will work wonders in the end.
No need to ask for permission then. :-)
/Roger