Code is a little bit like an apartment. If you put in conscious effort to keep it clean, then small changes require little effort. But if you let dirty dishes, laundry, trash, etc. pile up for weeks, then even the smallest changes seem overwhelming and frustrating.
I worked on one team that had a really smart system -- any desired refactorings / tech debt would be written on blue index cards. Every sprint, we'd meet up to discuss them as a team and advocate for the ones that we felt most valuable. The ones that had consensus would make it into tasks for the sprint board. This worked great because it cut out low value refactorings (you know those ones that only one engineer wants that everyone else disagrees with). Meanwhile, the refactorings that would be valuable to the whole engineering team got done -- even if they were big, multi-day refactorings that touched a lot of systems. This discussion helped everyone get on the same page on the ideal strategy for them and reduced the ninja-changes that caused more hurt than help. The blue color on the kanban board also helped the wider team understand that there would be no outwardly visible change, but it was an important task because the majority of the engineers agreed on it. I liked this system as it was a good way to get sometimes very complex/difficult refactoring improvements done while still having support of the team and fellow engineers.
Refactoring means rewriting the code to be more readable without changing the behavior. By "without changing the behavior" we don't mean all the behavior, we just mean all the behavior that we care about, which implies, if we actually care about it, that we've written tests for it. What this means is that there is no such thing as refactoring if you are not: 1. writing tests 2. writing tests that actually test all the behavior you care about So the bar for entry to refactoring is at least as high as: you can write good tests. I've rarely worked for a company where I've come across more than 1 other person who even *could* actually write good tests, let alone who did. Lots of people talk about "refactoring" though. What this usually meant *to them* is something very different: just whinging that "the code is bad" and "I wish we had time to make it good" where they really had no realistic plans for how to change the code or even understanding of why or what about the code was "bad" to begin with.
No thats just management style meaning of refactoring. I never refactor without adding. Thats why software. design has become to terrible expensive despite the progress.
We use a somewhat new technology that not everyone is comfortable with yet, so I like to use refactorings to give the rest of the team concrete examples of best practices.
I just mix both DRY and YAGNI. If i noticed, i wrote a similar thing twice or three times it goes into functions. But on the other hand, i ignore perfectionist feelings to extend code functionality or generalise stuff until i do encounter the other situations.
You should always be able to change the code. If you feel like you might break something by refactoring a module because it is too complicated to understand exactly what is going on, there are three solutions : - if it is doing complex logic (like math or a complex algorithm), isolate that thing and test the shit out of it - if it is using features of the language you are not familliar with, then go learn them and comeback. - if it is not doing anything complex in terms of logic (like moving data around, calling an API) you should absolutly refactor it. It means that something else than the logic being implemented is difficult to make sense of. Sometimes just picking the wrong abstraction or having too much inheritance can make it hard to know exactly what happens. Sometimes it is about architecture and not having a clear flow of the data or of the interactions. The idea overall is "programmers should be in control of the their code". Your job is to make the computer do the do, and understand how it works. If you don t understand the code, unlike management, you don t have people under you who will have to figure it out for you, you are the one responsible for that.
Code is a little bit like an apartment. If you put in conscious effort to keep it clean, then small changes require little effort. But if you let dirty dishes, laundry, trash, etc. pile up for weeks, then even the smallest changes seem overwhelming and frustrating.
Even big problems benefit from small changes over time.
I worked on one team that had a really smart system -- any desired refactorings / tech debt would be written on blue index cards. Every sprint, we'd meet up to discuss them as a team and advocate for the ones that we felt most valuable. The ones that had consensus would make it into tasks for the sprint board. This worked great because it cut out low value refactorings (you know those ones that only one engineer wants that everyone else disagrees with). Meanwhile, the refactorings that would be valuable to the whole engineering team got done -- even if they were big, multi-day refactorings that touched a lot of systems. This discussion helped everyone get on the same page on the ideal strategy for them and reduced the ninja-changes that caused more hurt than help. The blue color on the kanban board also helped the wider team understand that there would be no outwardly visible change, but it was an important task because the majority of the engineers agreed on it. I liked this system as it was a good way to get sometimes very complex/difficult refactoring improvements done while still having support of the team and fellow engineers.
I don't always refactor my code, but when I do, I pave a six-lane highway to new features
Refactoring means rewriting the code to be more readable without changing the behavior. By "without changing the behavior" we don't mean all the behavior, we just mean all the behavior that we care about, which implies, if we actually care about it, that we've written tests for it.
What this means is that there is no such thing as refactoring if you are not:
1. writing tests
2. writing tests that actually test all the behavior you care about
So the bar for entry to refactoring is at least as high as: you can write good tests.
I've rarely worked for a company where I've come across more than 1 other person who even *could* actually write good tests, let alone who did.
Lots of people talk about "refactoring" though. What this usually meant *to them* is something very different: just whinging that "the code is bad" and "I wish we had time to make it good" where they really had no realistic plans for how to change the code or even understanding of why or what about the code was "bad" to begin with.
No thats just management style meaning of refactoring. I never refactor without adding. Thats why software. design has become to terrible expensive despite the progress.
We use a somewhat new technology that not everyone is comfortable with yet, so I like to use refactorings to give the rest of the team concrete examples of best practices.
I just mix both DRY and YAGNI. If i noticed, i wrote a similar thing twice or three times it goes into functions.
But on the other hand, i ignore perfectionist feelings to extend code functionality or generalise stuff until i do encounter the other situations.
That sounds like a pretty balanced approach!
Thanks , high five 🙏🏻
underrated, great video man
Glad you liked it!
You should always be able to change the code. If you feel like you might break something by refactoring a module because it is too complicated to understand exactly what is going on, there are three solutions :
- if it is doing complex logic (like math or a complex algorithm), isolate that thing and test the shit out of it
- if it is using features of the language you are not familliar with, then go learn them and comeback.
- if it is not doing anything complex in terms of logic (like moving data around, calling an API) you should absolutly refactor it. It means that something else than the logic being implemented is difficult to make sense of. Sometimes just picking the wrong abstraction or having too much inheritance can make it hard to know exactly what happens.
Sometimes it is about architecture and not having a clear flow of the data or of the interactions.
The idea overall is "programmers should be in control of the their code". Your job is to make the computer do the do, and understand how it works. If you don t understand the code, unlike management, you don t have people under you who will have to figure it out for you, you are the one responsible for that.
This comment will help recommend this video to others
Thanks, Brandon. Much appreciated!