![]() Some might provide “absolute” information, like the violation of a coding standard, and other will just produce “smells” that needed to be manually examined. There are plenty of them available for code analysis or test coverage. Tools to detect some of the technical debt issues have existed for a long time. Sometimes, it is the requirements or the concept that changes and you should refactor some to make variables names more meaningful. You just duplicate some code because you don’t know that the same feature is also implemented elsewhere in the system or you rely mostly on manual testing to verify an urgent change needed for a bug in production. You don’t have to be an evil programmer to create some debt, especially in large projects. For those who live in a less perfect world, technical debt could be created in all the software development activities: architecture, design, coding, testing and configuration management. ![]() ![]() Somebody even answered that if you had a good definition of “done”, your project should never create any technical debt. In a brief informal survey of Agile practitioners, the idea of putting some number on the amount of technical debt was mostly considered as strange. Could you try to measure your amount of technical debt? Could you use some tools to do this? These are some of the questions that this article explores. ![]() This concept refers to the work that needs to be done so that a software development project could be considered as “complete”. Technical debt is a metaphor coined by Ward Cunningham in 1992. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |