I agree, there are too many who show up just enough to collect the paycheck! Those of us who care don't have to play by their rules, though. I have worked in an environment where I was even made fun of for trying to improve the code, after a year or two of slowly picking away at it, I at least succeeded in convincing the haters that what I was doing had value, even though they were still not willing to participate. The code did get better in the end, it just took much longer than if everyone had done their part. At the end of the day, I'm the one who needs to sleep at night knowing I was making things better for the next guy, and not worse.
Toxic comments here. This is sound advice. People that dont do this should take more responsibility for the quality of their own work. You are the one deciding how to build new features, you are the one deciding how much time that new feature takes.
Yeah sure. Design patterns help to replace legacy code slowly. Adapters make the new code compatible with the old code. Strategy patterns switch between old and new implementations. Factories with feature flags hide the new implementations until they're ready to deploy. Once everything is migrated, drop the adapters and factories and rewire the calling cope. As said, it'll take some time to pull that off.
@blucyk I mean it depends on the context of your product. There's no silver bullet. In the end that product needs to make money, so ultimately it's a business decision. If the project is small, you might get away with a big bang rewrite. If that's not possible, you can do a slow refactoring to keep the product alive or you can do a big rewrite in favor of a new product. Even for rewrites there are lots of ways like shutting down the entire thing or just partially shutting down some features. It really depends on the situation.
OK, Uncle Bob. Now try to give advice for an untestable system that is modified at such a pace that you do not have the chance to introduce the improvements you suggest. Also, what's the point if they are looking for ways to replace it with a proper system written by an IT company? The changes you suggest add unnecessary noise, making the code review harder.
He answers that here. Every time you modify code (to add new features, etc), make it a little more decoupled, too. It’s a nightmare to refactor an entire code base, but it’s trivial to refactor a function or two.
@@funkdefied1 You did not see the code I am talking about. While at time I succeed at decoupling and other improvements, it's not a trend but occasional one step forward with two steps back.
Why are you so mad? Is just a general advice for a general example. There are always exceptions and you should be able to validate this approach to your current situation
@@leandrowitzke6405 You are correct; there are always exceptions. Why I am so mad? Maybe you should first explain to me why people live in a dogmatic world and only admit the existence of the exceptions only when a mad man like me comes along and starts asking inconvenient questions.
@@jacekjacenty At what point has anybody been dogmatic? It’s just helpful advice from fellow devs. Feel free not to follow it, the code police will not lock you up. If the code is going to be replaced with ‘a proper system’ then that would indicate the feelings of the stakeholders. I’d personally challenge the statement that changes add unnecessary noise making the code review harder. Having smaller code reviews should help resolve that issue & pair/mob programming would make that step unnecessary or very quick. That’s just advice though, we’re just trying to help our community of fellow developers.
That's applicable to devs that cares. There are too many devs that do not care.
I agree, there are too many who show up just enough to collect the paycheck! Those of us who care don't have to play by their rules, though. I have worked in an environment where I was even made fun of for trying to improve the code, after a year or two of slowly picking away at it, I at least succeeded in convincing the haters that what I was doing had value, even though they were still not willing to participate. The code did get better in the end, it just took much longer than if everyone had done their part. At the end of the day, I'm the one who needs to sleep at night knowing I was making things better for the next guy, and not worse.
Toxic comments here. This is sound advice. People that dont do this should take more responsibility for the quality of their own work. You are the one deciding how to build new features, you are the one deciding how much time that new feature takes.
Yeah sure. Design patterns help to replace legacy code slowly. Adapters make the new code compatible with the old code. Strategy patterns switch between old and new implementations. Factories with feature flags hide the new implementations until they're ready to deploy. Once everything is migrated, drop the adapters and factories and rewire the calling cope. As said, it'll take some time to pull that off.
What alternative do you suggest?
@blucyk I mean it depends on the context of your product. There's no silver bullet. In the end that product needs to make money, so ultimately it's a business decision.
If the project is small, you might get away with a big bang rewrite. If that's not possible, you can do a slow refactoring to keep the product alive or you can do a big rewrite in favor of a new product. Even for rewrites there are lots of ways like shutting down the entire thing or just partially shutting down some features. It really depends on the situation.
What mr uncle is forgetting here is, that you only need to prove your code changes work with tests if you cant test in production.
Uncle Bob is right. I've done it that way. It works.
First
OK, Uncle Bob. Now try to give advice for an untestable system that is modified at such a pace that you do not have the chance to introduce the improvements you suggest. Also, what's the point if they are looking for ways to replace it with a proper system written by an IT company? The changes you suggest add unnecessary noise, making the code review harder.
He answers that here. Every time you modify code (to add new features, etc), make it a little more decoupled, too. It’s a nightmare to refactor an entire code base, but it’s trivial to refactor a function or two.
@@funkdefied1 You did not see the code I am talking about. While at time I succeed at decoupling and other improvements, it's not a trend but occasional one step forward with two steps back.
Why are you so mad? Is just a general advice for a general example. There are always exceptions and you should be able to validate this approach to your current situation
@@leandrowitzke6405 You are correct; there are always exceptions. Why I am so mad? Maybe you should first explain to me why people live in a dogmatic world and only admit the existence of the exceptions only when a mad man like me comes along and starts asking inconvenient questions.
@@jacekjacenty At what point has anybody been dogmatic? It’s just helpful advice from fellow devs. Feel free not to follow it, the code police will not lock you up. If the code is going to be replaced with ‘a proper system’ then that would indicate the feelings of the stakeholders. I’d personally challenge the statement that changes add unnecessary noise making the code review harder. Having smaller code reviews should help resolve that issue & pair/mob programming would make that step unnecessary or very quick. That’s just advice though, we’re just trying to help our community of fellow developers.
omg this snake oil seller come on.
@@BestHKisDLM It must be my lucky day, because I didn’t pay anything to the seller for this 🙄