You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
|
|
|
|
|
# Infos
|
|
|
|
|
|
|
|
|
|
|
|
auth-name : naomi rosenberg
|
|
|
|
|
|
tag : refactoring, micro-management, professionalism
|
|
|
|
|
|
|
|
|
|
|
|
need travel fee : N
|
|
|
|
|
|
need room : Y
|
|
|
|
|
|
Location : Planet Earth
|
|
|
|
|
|
|
|
|
|
|
|
# How Stealth Refactoring is Wrecking our Codebases
|
|
|
|
|
|
|
|
|
|
|
|
Because management are perceived not to value refactoring, developers fear being “told off” for doing it. So we refactor less than we’d like to, and when we do, we often sneak it in, hidden amongst functional changes.
|
|
|
|
|
|
|
|
|
|
|
|
We know insufficient refactoring leads to technical debt. Stealth refactoring creates problems, too. Reviewing a diff mixing functional and non-functional changes is time-consuming and error-prone, costing money and introducing bugs. Also, stealth refactoring tends to focus only on the “geographical area” - the function, file or module - that we are “touching” at the time. What are the implications of that for the coherence and consistency of our codebases?
|
|
|
|
|
|
|
|
|
|
|
|
I will make some technical suggestions for optimising how we refactor, but the main issue is cultural. Is our shame around refactoring entirely due to management, or are devs responsible too? How can we sell simplicity to people who may not be aware of its value? Can we create a culture that legitimises - or even rewards! - a practice that is, after all, essential to developing good software?
|
