321–330 of 346 posts
Also meditation is good. Sometimes I get so upset at legacy code that I have to stop and meditate.
2. Document the existing codebase
3. Start writing unit test and/or integration test for the existing codebase
4. Adopt a mindset of ZERO tolerance for defects making it to production
5. Begin at the lowest layer of the codebase (usually data access) and execute refactorings there to either encapsulate areas of potential change or business domains
6. Once the data access has been refactored to "good enough" work on the next layer up and continue this process to the top, this should enable you to have an architecture that is closed and decoupled.
The best thing to do is to gradually rewrite it by always leaving the code in a better state than it was before. For example, you're tasked with a non-trivial adjustment to an API endpoint--instead of adding to the mess, extract the endpoint out into it's own file and rewrite/clean it up. Write tests beforehand if that makes you more comfortable.
Using this technique, my current team has been able to slowly rewrite our codebase from spaghetti JS (read: thousand line JS files) into a more structured TypeScript project. It has a long way to go, but doing an incremental rewrite works wonders.
And like another poster said, being able to read legacy code is a good skill to have. After all, you'll need to understand it before rewriting it.
Earlier quoted context omitted.
>and micro services. Work in the cloud. Avoid enterprise. How is this even related? Worst code I've seen was in financial sector, but the project is so huge that is no chance of upgrading it without complete rewrite, 65% of code when I left it was still in Java5 with no option to upgrade to 7 any time soon, it's just too big, so we can understand why it's shit. Second worst code was in a startup, micro-service orient…
Thanks. Saved me a response :) I am in an Enterprise and we have deployed cruft code into the cloud :) and were even cloud native or whatever bullshit bingo brings up next in terms :)
Here's a hard earned tip. The first few months, nobody's going to expect much from you anyway. Try to stretch the time you're 'getting up to speed with the code' as long as possible. But in that time, write as many tests as possible. Don't tell anyone unless they ask; if there is no testing culture, they'll think you're just wasting your time on it. Then at some point you will be expected to start delivering value. A…
If moving is not an option, then follow the parent's advice. Add all the missing tests as fast as you can. Explain what you are doing to your manager. And set up CI to email your team whenever anyone checks in breaking changes. This will motivate your teammate to start running your tests. If they are particularly narrow-minded, they will be unhappy about this. If this happens, reconsider your decision to stay.
Even after you write a lot of tests, coverage will be low. You will likely code some bugs that negatively impact the business. I urge you to find a mentor inside the company, a senior engineer or engineering manager, and show them code and explain the technical debt to them. Try not to blame your teammate for the situation, just explain to your mentor that you are concerned about introducing bugs. Ask them to keep your discussion confidential. Your mentor can back you up when your bugs negatively impact the business.
Then implement and run the tests. The code will fail some of the tests, so make sure that those tests really do correspond to the spec and then present the remaining failures to product owner/your boss. Maybe the spec will change, and then the tests will change and the code will pass. If there are still failures then get written instruction to fix the code.
Eventually you will have code that passes all the tests.
Now you are in control. You know what the code should do and that it does it. And best of all, you can make changes to the code and know if the code is still correct.
Additionally, you might find yourself looking at the awful spaghetti in a different way. After all, the spaghetti does exactly what it's supposed to. Maybe you can make it do it better and be more maintainable etc, but as far as anyone else cares, it'd better taste exactly the same or else you'll have screwed it up.
Earlier quoted context omitted.
>> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers. SOme people are really precious about their shitty code and can't take criticism, esepcially in small compan…
And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do know better than everyone else, but you ought to make damn sure of it before you open your mouth
I've been on both sides of this issue in the span of my career. I've joined companies with absolutely horrific code, and I've hired people who thought my code was shit. My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. Your job at first is simply to understand the code and demonstrate that you are able make improvements to it without breaking everything. Doing so wil…
In my mind, unit tests is not what you want to start with with a messy legacy codebase. It takes a huge amount of effort testing lots of already working code. Add unit tests for any new code, but try and implement tests for the entire system, functional/integration tests are also easier to argue for in terms for direct benefit for the customer. Unit tests are more for the developer and is harder to argue for.
Adding tests makes it easier to confidently refactor the code later on.
Earlier quoted context omitted.
And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do know better than everyone else, but you ought to make damn sure of it before you open your mouth
I think if it's so frequent that you're sick to your back teeth of listening to people complain about your code, it's probably a really sure sign that something is very wrong with the code.