Hi all! As most of us programmers I’m still learning to code, following my own journey and as much as I’ve tried to use the patterns that I’ve learnt to the best of my abilities and taking into account that I still need to improve in the software design patterns arena, I’ve had the feeling that some refactoring is always needed. Do you agree?
If so, might it be for some other reason other than programmers learning stage or skills level or might this be an inherent phenomenon from the complexities of programming or the diverse nature of the problems we need to address for the wide range of possible use cases.
If code is still under active development (new versions are being created, updates released, etc) then you’ll always have opportunities to refactor. Sometimes you are just recognizing better ways to do something . Sometimes the changes that have happened since a piece of code was written means that it’s no longer optimal. Sometimes you are updating some piece of the technology that you are using.
2 Likes
Thank you so much for your response @ArielLeslie Let me also ask. Is it then safe to assume that we must also adapt our coding style not only to be SOLID, DRY and Test Driven, but to also take refactoring into account? So that it makes our refactoring easier in the future?
Also, is there any good resources you know to expand on this and learn more about it?
You definitely want to write code to be kind to future developers, including yourself. I don’t know of any resources off the top of my head, but I’m sure that there are some good technical op-eds on the subject if you dig around.
2 Likes
FWIW, I’d focus more on writing code that
-
works
-
you verify works
-
you can change in the future
There are a million things like SOLID, DRY, TDD, etc. While it is important to consider good software design practices, the best way to get good at writing code, especially on a team of developers, is to write code, especially while working with others. Don’t let researching get in the way of doing!
2 Likes
Thank you, is great to validate the feeling. It’s hard and stressing to be 100% compliant with all this standards all the time. I guess sometimes they get in the way and I also imagine sometimes is more of a trade off isn’t it?
There is definitely a trade off between different best practices.
I think that it is important to be aware of best practices and stop and plan before you write code, but at the end of the day you gotta write the code.
I often ask myself similar questions, but I think the more experience you gain as a programmer, the bigger your ability to tell if “this is really really bad code” or “this isn’t 100% awesome but it doesn’t hurt to leave it like that”.
Nobody likes to write bad code, or even worse, committing the crime of BAD PRACTICE (omg the fear).
As for refactoring, I think it’s unavoidable, unless you’re a genius that already knows exactly what the code should look like in the final version, before even writing the first line.
I actually enjoy it. The first version is always quick’n’dirty. Optimising a piece of code and watching it shrink from 100 lines to 30 while increasing readability makes me happy 
1 Like
Another thing to consider is that a lot of shops are agile now. One of the tenets of agile is that the specs can change at anytime, even while you’re in the middle of developing. Features get added, dropped, altered. And since you’re building incrementally, there are often spots of less than ideal code that need to be improved. Agile has many benefits, but this is one of the downsides, imho. Some shops allocate as much as 25% of their dev time to refactoring.
1 Like
That’s really good to know, thanks.
As a beginner freelancer I haven’t had the chance to be exposed to this kind of experiences. I imagine it can be hard work when features get dropped or the specs change drastically, I guess the upside is that you must learn a lot during such times, you become battle tested I suppose.
One of the ideas of agile is that you are getting constant feedback from your customers so you adjust to them. This is opposed to the “waterfall” paradigm where you agree on the specs and come back with a finished product in 8 months. Agile can be frustrating sometimes for sure, but there are a lot of advantages.
It is becoming the norm.
and now that I think about it, 
it’s weird but you are right it felt good.
