Old code sucks but works and is well tested, afraid to change it? - Page 1
Forum section: electronics / general

author: daqq
author_rank: Super Contributor
timestamp: January 07, 2020, 09:24:52 am
content: Hi guys,For some time I've been working on a big project, several years in fact. During that time I pretty much moved up from "well... yeah, I've poked and prodded an FPGA at uni" to an FPGA developer. I would never claim to be an experienced guru, wise old sage, or anything along those lines, but I get stuff that needs doing done. Nothing particularly amazing, but a massive step up from the classic digital alarm clock at uni. By the way, this forum helped me greatly, the community here is simply amazing, big thanks to everyone.I've been looking through the code that I did at the start of the project, which includes the basic building blocks that bind all of the parts together (communications arbiter, some memory management, that sort of stuff) and hasn't been touched for years. And, well... eww... I've learned a lot between now and then and it shows. I've had a dozen insights like:- this thing could be done far more efficiently with a simple few lines- ewww...- wow, this could have been done with about half the resources...- why does this work?- on what illegal herbage was I whilst coding this?I have the urge to redo whole modules, but the issue is that the way it's written now works and has been tested for a long time. It's a proven working bad solutionI can either rewrite several base modules and risk subtly screwing up things in a way that I can't verify in a short time, or leave it alone and leave an apology note for future me or whichever poor bastard that gets the task of building something more on ugly foundations (which will be possible, but somewhat painful).The boss told me to keep it, since it's technically a cosmetic issue at the moment and there are more pressing things. Which is true.Basically, it just irks me and both of my options suck. Do you have similar experiences, feelings?

author: Siwastaja
author_rank: Super Contributor
timestamp: January 07, 2020, 09:50:59 am
content: Don't rewrite just because you feel the modules suck, but do rewrite whenever you find one of them breaks or has a bug that would require more than a few minutes to fix.Having old shitty code that really works is OK; maintaining old code that everybody thinks "works", but actually doesn't work, is a nightmare.Your self-confidence has likely improved even more than your skills. If you rewrite them now just for the sake or rewriting, you will find yourself in 5 to 10 years, even more experienced, looking at them again, "this sucks, it's almost as bad as the original was!"Beginners are prone to make very low-level mistakes, spaghetti code, etc. More confident "early professionals" are prone to make mistakes big-time, thing about using the wrong, bloated, trendy "professional" frameworks they have heard about in their professional work life. The former are easier to fix than the latter.The most horrible pieces of shit I have seen have never been made by beginners.

author: magic
author_rank: Super Contributor
timestamp: January 07, 2020, 09:59:10 am
content: I agree. Rewrite on as-needed basis when you want to change something and feel like writing it from scratch is easier than deciphering the original code. Otherwise who cares, it ain't brokeI will expand a bit. I have actually been involved in maintaining software written years ago by a young genius whose favorite keys were apparently CTRL+C and CTRL+V. He knew his entire codebase inside out so he could always fix bugs in every copy of the affected code, except for those times he forgot about somethingIn addition, the project evolved from a simple proof of concept to increasingly heavy production use and was full of inefficient solutions and crazy hacks added to improve performance in desperation.So our policy was exactly as above. For trivial bugfixes, just do them and don't forget to find all copy-pastes of the buggy code if we are at that. If they are exactly identical, replace them with one functionFor any serious change though, we did a rewrite. That often ended up replacing 2000 lines with 200 and increasing functionality by at least 20%But it wasn't for free. You have to read the original code, find out what uses it, understand all weird edge cases and design a new solution. Then test and debug it, and you could still end up missing something. That's a big time sink so it was only done when necessary.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: January 07, 2020, 10:24:25 am
content: Refactoring is always fine, as long as it's equivalent. Simple syntax and style changes are pretty safe, but structural changes are harder to justify.To justify them, have some means of showing equivalence. Inspect the compilation (RTL in this case, or in software, the machine code perhaps). Create test fixtures for blocks or systems, and run tests. Make sure the tests themselves are sufficiently comprehensive.If you can't justify the effort spent on these, or can't accept the remaining risk (mistakes in the fixtures or oversights in the inspection), indeed, just leave it. Maybe comment it carefully, to indicate to others why it is the way it is; outline steps like these in the event someone wants to do it in the future; etc.Tim

author: spudboy488
author_rank: Regular Contributor
timestamp: January 07, 2020, 12:30:47 pm
content: Bad code usually includes bad documentation. If it's working, maybe go through and update the comments throughout the code so if something comes up in the future, it might be easily found and corrected.

author: thinkfat
author_rank: Unknown
timestamp: January 07, 2020, 01:34:44 pm
content: If you have kept a halfway sane structure, with actual modules and not just 'source 1.c source2.c...' and formulated interfaces between them, refactoring whole modules should not be a huge task. However, if you feel an urge to puke looking at the structure, the first step is to think about the design again. Time is best spent thinking, not coding, under such circumstances.

author: Berni
author_rank: Super Contributor
timestamp: January 07, 2020, 01:52:51 pm
content: When it comes to HDL code good testbenches should make sure that you don't break anything. So if none exists write a nice extensive testbench that tests lots of cases, test it on the original module to make sure it works. Then rewrite it and test it again with the same testbench and all should be well.The problematic part is when a module contains a unknown/undocumented bug that doesn't seam to pose any serious threat to its operation, but in a system some other module might depend on that bug to work correctly. A testbench might not test for it so it doesn't care and the unknown bug might not make it into the rewritten code.So yeah rewrites are never really fully safe. Perhaps save them for when you want to add a major feature and just go rewriting any modules that the feature touches since you will have to read trough them and test them anyway.

author: hli
author_rank: Frequent Contributor
timestamp: January 07, 2020, 02:20:51 pm
content: "Code sucks" usually means "its hard to understand". And that's usually the reason no-one wants to touch it - if you don't understand it well enough, you cannot safely make changes. If its sucks, but is young enough so the developer still knows what it does (and agrees that it sucks), then its refactored soon enough. If you detect that its hard to understand only after not looking at it for 6 months, well, then it sucks ;-((The exception being the copy-and-paste issue already mentioned - but this is usually solved easily enough, sometimes even your IDE can point you to all the places where this has happened and handle it for you).

author: madires
author_rank: Super Contributor
timestamp: January 07, 2020, 03:58:01 pm
content: Inefficient and ugly code is all over the place. You can't escape it. Since one is rarely paid for beautiful and efficient code you have to choose the best way to get the job done. Don't waste resources to rewrite everything for some minor changes. But for long term projects it might be worthwhile, e.g. to be able to add new features more easily.

author: Red Squirrel
author_rank: Super Contributor
timestamp: January 09, 2020, 02:03:37 pm
content: What I tend to do is write better code in parallel (ex: something that should have been done in a more OOP way I will write class/functions for) but won't touch the existing code. Next time I need to do something similar I use the new way. I eventually phase out the old code over time but only as needed.