Never rewrite code?
Вставка
- Опубліковано 3 лип 2024
- Is it a bad idea to rewrite code or an entire system? As developers at some point we want to rewrite for various reasons. Often times it's because we simply don't understand the existing codebase or think it's a tire fire. But is the benefit there? Sometimes, yes. Sometimes, no. It's a pretty nuanced topic around cost/benefit.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - Наука та технологія
I say rewrite, Take what you have. 1) Document the design. 2) Build UNIT TESTS, 3) Use newer constructs. 4) After putting them behind unit tests, reuse your best objects and routines. 5) Take advantage of better OO, SOLID and DRY principles. 40+ years of experience here. I'm tire of falling into sh*t code because few want to rewrite.
Curious, would you do a rewrite for free and only if it generated more net profit than before, then get paid?
You don't always get a buy in to be paid to do it. In some cases it proved valuable to do some extra time after hours to get a proof of concept. If successful you have most of the pattern laid down to get the project going quickly. Sometimes promotions are surviving the next layoff is how you get rewarded.
I strongly feel like the general engineering answer applies to the question "Should you do a rewrite?", which is: it depends.
Over the past 16 year I've been involved in many rewrites (unfortunately, because I like greenfield better). No rewrite was ever the same. The existing legacy product always worked "fine", but there was always a reason to rewrite: code was unmaintainable, refactorring took more than rewrite. Worked fine at small scale, but over X users performance took a nosedive, nobody understood the system anymore because all domain experts left. No confidence in building extra features, because the codebase was already too big and there were zero automated testcases written, every change would break the system in ways you would not have guessed.
Deciding on doing a rewrite is not a developer-only decision, enough stakeholders must be involved. I like this video because you consider the context of the situation.
I’ve been doing rewriting of entire projects a few times with full success. Extremely painful process, so only for experienced. You may be surprised how many details is covered in old code. I rewrote iOS app from OBJC to Swift in 5 years and backend system from plain PHP to Laravel in 3 months. And a few others in my 15 years career.
That Obj-C ==> Swift rewrite seems like an example of one of the major cases when a rewrite is more likely to be appropriate than not. Specifically, Apple is replacing Obj-C with Swift it's getting harder to hire devs to work on the old code. Companies with a sizeable Cobol code-base are an even more extreme example of the same thing.
You might be forced if the language or framework you are working is losing traction and is not / no longer supported on your current platform.
Yes, that could be a reason.
But you gained a lot of knowledge since you first wrote the code. You now have the whole picture, you know which parts you don't need etc. You know the business logic and requirements much better.
After 5 years every dev can write much better code. Sometimes even after 6 or 12 months.
I remember reading and referencing many Joel Spolsky articles back in the day. I think the most memorable content for me is "Why I hate frameworks".
Something Ive suggested to colleagues over the years is if you think something is ugly that you have a reason to change, isolate it and rewrite that piece. Usually I would be referring to a smaller section of code that maybe is tangled in a god class or something. I say write what you want that code to look like and have it called instead. Do that enough times as changes are required and eventually you'll be happier. The intent is to do this in the small and typically for a single branch of logic, to avoid doing to much at once.
I realized long ago developers would much rather write new code than maintain old code. This technique can allow for small improvements over time while empowering developers to do what makes them happy.
Some frameworks are good, some bad. Net framework for example is more a giant library where you can just take whatever you want.
@@GnomeEU if you haven't read the post, you may look it up. It's pretty entertaining
Have you ever wondered if you would have gotten to your skill level as a developer if you wouldn't have rewritten stuff? I wonder if you mostly read code and merely do little changes here and there you miss out of great learning experiences building a complete system. Any thoughts?
I have never done a full rewrite, there was always a way to adapt the code to allow fast and reliable business process testing. Writing tests is the best way I know to learn if any kind of rewrite is necessary.
We've had two rewrites. Our main application was in a VB6 desktop app that we needed to bring to the browser. So we had the brilliant idea to go with Microsoft's shiney new Silverlight framework 😂. Fast forward a few years later, rewriting that shit again...
Yes, Microsoft screwed a lot of developers by abandoning technologies that they promoted. One of the main reasons that led me to abandon their platforms altogether.
@@fernandoacorreiatbh, MS still handles out better than e.g. Google. Nowadays MS gives at least 3 years notice before shutting down support
However this is still a naive viewpoint. What really mattered was that after our nine months of beautiful architecture and coding work we were making approximately 10k/month more than what our stupid production prototype made for all of its shortcomings.
I did not understand this statement. What did they mean? Was it worth to rewrite?
As always, you covered this topic very well. I have had a lot of similar experience.
It depends on the kind of software you develop for sure. But in the environment I'm working in, which is frontend development, I prefer to constantly iterate. We update dependencies constantly anyway, and we constantly get new requirements that have to be addressed. The business logic changes all the time. So it's a good idea to refactor often to keep knowledge of every piece of code fresh across the team. This helps to avoid black-box and append-only code. And in case a bigger rewrite is due, this will also be easier to do without missing important bits of business logic. If we'd only patch new requirements on top of existing code, we would have an unmaintainable mess within months.
Context matters 🔥🔥❤❤
You can rewrite things as a last resort but you had better have a damn good reason, because it will almost certainly be extremely expensive and risky.
In my experience usually the question is not whether to rewrite or not, but how to isolate the broken parts you need to rewrite without losing connection to the rest that is still working (and maintainable!).
Nice overview. I was wondering about security considerations. We have some AngularJS projects that are flagged as security concerns. Rewriting these would have limited immediate consumer benefit, but could be worthwhile as an insurance policy.
How did you know? I needed this NOW, I have a SAAS application built in PHP, it's being used by clients but I'm thinking of rewriting in new technologies but I'm thinking WHY? I have few reasons but it takes a lot of work to rewrite.
I prefer a "if it isn't broken, don't fix it" approach. However, sometimes the code is written so poorly that you can't make changes without rewriting part of it. Often, I have to refactor the code incrementally, cleaning it up in small steps. Every time I've decided to quickly rewrite everything, it ended up in overtime for me and explanations of where I spent my time. I try to avoid making such fatal mistakes.
I wonder if we could create some metrics to gauge how much a rewrite could be worth. Perhaps fail rate, time to bug fix, how long it would take a mid full-stack engineer to ship a brand new form in the most complicated part of the app, how long it'd take to ship a feature that required data migrations as a result of db schema changes. I could see code bases (and eng orgs) having wildly different answers for each. Though I'm assuming we have an active code base, sounds like the cold fusion thing nailed it with essential functionality and does need to worry about any of the above.
Rewrite is fun but not profitable. Profit is not everything. Rewrite is not the only fun.
Ideally, code should be in a state that any change will incur fmt, linter or compiler or test suit to warn or err or revert the change. Then, your current code should be the unique solution of such specification.
Been in a rewrite from webforms to monolith mvc. Never made it to prod. The monolith was too big to build timely. Would have been better to redo the parts holding the business back, one at a time.
If you don't understand the code thats a total valid reason to rewrite it. How can you support a code base that you don't understand?
(from a retired dev, for example)
It's also some of the highest-risk code to rewrite. After all, if you don't understand what it does, how do you know what your rewritten code needs to do?
There are ways to manage that risk, but a big category of methods is to develop a thorough understanding of what the current code does.
@@jonathangalliher4474 yes but if you never dare to touch any old code then you can throw away your app after a few years, Cuz nobody is able to maintain it anymore.
This is what happens in many projects, that only get bigger and bigger and we never dare to touch anything.
I think to begin with, we need to define what "requires a rewrite" means. Do we mean when the code is not perfect. Do we mean when the code is not fit for purpose? Do we mean when using newer technologies would be more appropriate? Etc, etc. Then, once we establish that, then we can factor in things like value added by doing a rewrite, etc, etc. There should never ever be any hard and fast rules, such as "never do a rewrite" or "always do a rewrite".
You should always rewrite! All the time any time.
it depends......................................
Oh, a large rewrite. For sure this can be problematic. I thought this was going to be a discussion of refectoring or tidy-first mentality. This talk is a mature look at tradeoffs. I'm in the middle of a major rewrite and planning the migration makes me cry. Other systems are coupled to the original system through its database. I'm trying to decouple them and it's a house of cards.
But do you know for sure that the other 80 % of the features are not used by any of your customers?
So according to you, if you have a codebase that you understand and someone else gets onboarded and he sees the mess you created (that only you and/or a few other team members understand or partially understand) and he's struggling to understand and he won't fully understand it ever... this code is good enough?
What if the ones who understand the code leave? What happens then?
I think his point was just to be cautious about it and not to jump on the rewrite hype train recklessly.
If a codebase is complex, there is a good chance it's because the business logic is complex, and you won't do much better during a rewrite. Or at least not good enough to justify the cost.
So understanding the codebase is important before deciding you should do a rewrite, and make sure it's actually the code quality that's the problem. Or you'll end up with what you started with.
If the code works it's good enough yes, the documentation around it could suck though and that *might* be a good reason to rewrite but not necessarily.
But I do think some context is missing in the video. When talking about rewrite, does that include (small) refactoring, or not? Because the boy scout rule also still exists "Leave your code better than you found it" :)
@@Timelog88 Some projects tend to place pressure on the developers to ship fast, which has an impact on the quality of the code. The developers keep stating that the code works, but it needs refactoring (not a rewrite) and tests, but the focus is again on new features.
In this manner, after (let's say) two years, the project becomes a mess and almost nobody understands everything without a lot of mental effort and jumping through hoops.
I am against rewrites overall, but disagree with the statement "it's good enough".
So the ideal solution (if you're not thinking about switching the tech stack) is to refactor using tests, so you can get the code in a stable and sane state, so existing/new developers have an easier process when changing or adding new features without the fear of breaking something.
@cosoranxdrw I feel like you're saying exactly what Derek is saying. Use you jugement based on your context. If you need to change the code and add feature but no one is able to do it, clearly something needs to be done. Is it a rewrite ? progressive refactor ? The strategy is your's to take, there's no magic solution, just do what works for you. Not all devs are made equals, some have different background and skill sets. You have to work with what you have.
We just need to keep in mind the cost of a full rewrite and if it outweighs the benefits. Rewriting/refactoring something you don't understand is always a bad idea and sometime we devs are quick on the refactor/rewrite trigger when all you had to do was to take the time to understand the code and add a couple lines.
@@cosorxndrw You're literally describing a project I have been working on... for two years 🤣
And yeah, most parts of that codebase are currently "good enough". We don't need to change them now as there are no new behaviors planned for those features, so we don't touch them, no matter how much 💩💩is written there.
And when we *do need* to change that code, we refactor and add test first, before extending it.
And I think that is the message Derek is also trying to send, look at the context of why you want to change it and make sure that is a good reason, if not, don't touch it no matter how many issues the code has. If it ain't broke, don't fix it!
ua-cam.com/video/xCGu5Z_vaps/v-deo.html
This opinion is stupid. People dont rewrite arbitrarily. Engineers rewrite because they want to refactor. The way to rewrite is to refactor small parts of a system. Add Tests, Repeat until you're done. And you only do this if you need to. I.e. if the system has code smells or arch smells, if its failing and there are no unit test, or if its a legacy system without any tests.
"Engineers rewrite because they want to refactor." This alone is not sufficient reason for refactoring, unless the engineer also happens to be the owner of the company.
Refactoring is only justified if it brings real benefits to the company. If it does not, it's merely vanity on the part of the engineers.
Refactoring typically introduces new bugs and may disrupt things that were already working due to a lack of understanding of the legacy code. This is why tests alone will not guarantee the quality of the new code.
@@CassioRogerioEskelsen You are right. You can have 100% code coverage but... with stupid tests 🙂
Yup keep that old crap around. Too dangerous to touch it.
rewrites are taking times 1/10th of what it used to in the past bro. we got LLMs to do much of the work these days