Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
If refactoring takes you two weeks.... wow. Anyway, look up the broken window theory.
Also I don't see the point of the lines here. -
@junon Thank you that was a good read of the broken window theory. In our case the codebase is already broken... and I need to fight my own system to add another hack to make it work... but sometimes I should just refactor it for every and make it better.
-
Crost41084y@0x0000FFFF I offer theoretical advice, as the reason a code base gets like this is often includes management as much or even more than low developer skill in the team. In that case you can only do what you are not prevented from doing...
Anyway so the idea as others kind of said is that shit quality reduces speed significantly in the medium to long term according to actual research, and not just management gut feelings..
To fix this situation management must agree to reduced output over a long time depending on project size (but not significantly), and short time reduction from training devs. The alternative is what though? A slow crash and burn. Which may take years or months.
So start separating code into contexts, keep those contexts in good shape, slowly refactor until the code that should be in that context is there. This takes time and do it as you go works, but can also lead to pure chaos in the product since you never finish any area and the whole thing is now even worse. -
Crost41084y@craig939393 so yeah bare in mind whether you can actually finish that context. If not you need more management buy in I think.
When your code is now in context boundaries, has good testing, is written with knowledge of design principles like solid and maybe model driven design, probably you can slowly improve a system. Shit code in its own boundary is not as big a deal as shit code in a big ball of mud.
Most likely though you will be prevented from making improvements by managers that can't see beyond the next few years, or even weeks in some places... If so I would immediately give up and don't make it your problem. -
@r20408e122449d @bagfox just likes to mess with people..or was it some other green dot with shitload of ++.. 🤔
Everytime I am left with this choice...
rant
hacking vs refactor