I have gone through that many times. Personally, sometimes it was easy to adapt because those weren't so different from my ideals. I bet you have been in that situation, haven’t you? But, what happens when the project is completely different from your preferences? How should we work? Should we modify everything and make it our way? Or just the new things? Well, to answer this I’ll base it on “Future proof thinking”.
Doing it all again?
When you’re in front of the code of somebody else, maybe you'll feel like you are deciphering hieroglyphics. It’s probably that your first instinct is to think or try to “adopt” all to a “better” way, not to say, do it all again based on your ideals and standards. I’ve been in those shoes too and, from my point of view, it might not be the best approach you should take every time.
As developers, sometimes we think that refactoring all will allow us to understand all the code, which means that, in the future, we’ll be able to make changes easier and faster. It’s true; when you know the code and flow of the app completely you are the lord of those lands, therefore you’re able to know where you have to touch to fix issues and where to add or modify a new feature.
However, we have to think about our work as a part of a team, so, how much time do you think that it will take? Does the project have that time available? Or do you think that somebody will support you on this decision?. I’ll say from my experience that when you start to work on a project that it’s already started, usually they have a timeline, so time will be essential at that point; a refactor doesn't sound viable in this situation.
Additionally, we need to be realistic about the fact that these kinds of changes, most of the time, don't add value to the end product. Let’s think these slowly, a code refactor is a transparent change for both the rest of the team and the project (i.e., it will not be tangible for them). Stop there. I know that you’re going to think that it happens even with work that generates value or features for the project, but we need to keep in mind that sometimes the best that we can do it’s reaching the MVP.
In a way, we can think of a code refactor as a luxury, but why? Because, in most cases, it’s just for our benefit and comfort. Maybe saying it in that way sounds rude. I know how difficult and frustrating it is to be limited in situations like that, but being considerate with the future of the project and the rest of the team, I think that a refactor of the code might not be the best decision. Sometimes we don’t need to reinvent the wheel.
My stuff, my way?
Undoubtedly, all of us have ideas about how we should program, I guess that this could be the primary reason why we would consider modifying the code where we will be working, so it meets our standards. We have to admit that sometimes we add a tab where there wasn't or maybe add spaces or other kinds of trivial changes on existing code. I have to declare myself guilty of that.
Well, until this point everything is OK because you will work your way. This will make your adaptation period easier and make you feel comfortable, also you probably will work faster (it could have other pros, too), but what will happen when somebody else comes to work on the same code? As a result, the code will not be consistent and the learning curve will be bigger, maintaining it will become a nightmare, because now two different machines work together so, at some point, there are going to be as many structures of code as developers working on it.
You could also be the first or the second to work on that code, the possibility of being the last of the list of developers exists, so added to the fact that you’ll need to work and understand the code of other people, you’ll have to learn how this Frankenstein’s monster works.
Based on all the points that I just exposed, and even though sometimes we would feel that we are not doing the best or the right way, l concluded that the best way we can follow up with these situations is to try to learn and keep the current format and structure of the code, because it will make it consistent and easier to understand for new team members or teams, basically it’ll be maintainable. In addition to the above, the timelines will not be affected, so this decision is “Time proof”.