Unfortunately if you let Junior play in legacy code once, it’ll learn some nasty habits and make more of it from scratch, usually when you’re trying to sleep.
How do you even fix it, when the design is broken. Sure you can make an alternative function, without all the warts, but how do you convince the “seniors” to not use the old functions, because it is in fact problematic for various reasons.
We have a separate C-library that returns all strings by ringbuffer. Why is that a problem? Call into the ringbuffer enough times, and it will wrap around, overwriting earlier strings. This, and other bad code practices such as broken multi-threaded code (not threadsafe), and more.
If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).
Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.
If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.
It wish it was that easy. It is a deep rooted problem, because of several other factors.
There’s not just one function that is l dependant on the ringbuffer, but multiple functions in multiple libs and dll’s. Some if these dll’s and libs are used by us, some are used by another department and some are used by both. It has to stay C-code, in order for both departments to be able to use the library. The other department is using pInvoke to call it from a C#-application, or from other dlls. We use it as library in a C+±application, but also for us it might happen indirectly by being called from other libs or dlls.
A proper fix is therefore an immense task, and requires coordinations between multiple teams.
About deprecation, well, we handle warnings as errors, so adding a deprecated-attribute wouldn’t compile. I could add a warning-assert, but that annoys some of the senior developers, and then I have to remove it again.
About code review, many of the seniors often don’t do them and just commit directly…
To sum up, it’s easier to phase it out instead of turning everything upside down.
Let him play in the legacy code. You can just hose him off later before letting him back into the office so he doesn’t track it everywhere.
Unfortunately if you let Junior play in legacy code once, it’ll learn some nasty habits and make more of it from scratch, usually when you’re trying to sleep.
It’s true, spaghettification sauce stains clothes. Best keep Jr out of it entirely.
I don’t want that shit all over me though. That’s why I hired junior!
That’s what the line represents. So they can pull you if you do something nasty.
How do you even fix it, when the design is broken. Sure you can make an alternative function, without all the warts, but how do you convince the “seniors” to not use the old functions, because it is in fact problematic for various reasons.
We have a separate C-library that returns all strings by ringbuffer. Why is that a problem? Call into the ringbuffer enough times, and it will wrap around, overwriting earlier strings. This, and other bad code practices such as broken multi-threaded code (not threadsafe), and more.
If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).
Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.
If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.
It wish it was that easy. It is a deep rooted problem, because of several other factors.
There’s not just one function that is l dependant on the ringbuffer, but multiple functions in multiple libs and dll’s. Some if these dll’s and libs are used by us, some are used by another department and some are used by both. It has to stay C-code, in order for both departments to be able to use the library. The other department is using pInvoke to call it from a C#-application, or from other dlls. We use it as library in a C+±application, but also for us it might happen indirectly by being called from other libs or dlls. A proper fix is therefore an immense task, and requires coordinations between multiple teams.
About deprecation, well, we handle warnings as errors, so adding a deprecated-attribute wouldn’t compile. I could add a warning-assert, but that annoys some of the senior developers, and then I have to remove it again.
About code review, many of the seniors often don’t do them and just commit directly…
To sum up, it’s easier to phase it out instead of turning everything upside down.
I’m sure that ring buffer started out as a “temporary solution”.
God, I would love that so much