231–240 of 346 posts
Earlier quoted context omitted.
A software project can be fast, reliable, and secure while also being extremely poorly engineered and extremely difficult to maintain and extend.
Not a large one.
Always loved this quote.
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…
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…
Also I want to add that allocating time for a refactoring or fixing legacy code is hard to justify most of the time. Instead I try to follow the "boy scout rule":
On every bug fix or new feature you work on "Leave Things BETTER than you found them". An small change like properly naming a class or a variable, or just writing a readme file explaining something will help you and your team in the future.
https://medium.com/@biratkirat/step-8-the-boy-scout-rule-rob...
Is it buggy? Is it insecure? Is it slow? If the answers to those questions are no. Then you the problem and you should look for employment elsewhere. You are unhappy in that job, and you rewriting the codebase would potentially make the above questions answer to a YES, inflicting damages in the company. Now, if the above questions have yes as an answer. Talk to your manager, explain how it won't scale, how it is hack…
Why can't you badmouth the previous developer? Sometimes they were simply shit developers and wrote large quantities of shit code. Circumstances be damned, I've seen a few developers that should outright find a new career.
You might claim it is spaghetti code because you believe in some dogma that your predecessor did not adhere to. Maybe hold back for a while and try to understand what's going on first?
I've been there as well, but after going through quite a few 'paradigms' I have to say that I prefer spaghetti to
lasagne (layers and layers and more layers of crap)
calzone (looks nice on the outside and has test cases for every line but thats because the logic is so contorted and mutable state is everywhere)
the mafia that tells me I can't use this keyword or other, how long lines can be, that I can't use a single letter variable name, etc pp
Yea, so you need to write some tests before you worry about that.
Fixing tech debt on a large mission critical code base requires years of work. If you stay a year often the best you can hope for is to leave them behind a decent set of tests.
Rewriting random code as a codebase newbie is always a mistake. You will get things wrong. Mistakes can be delayed a long time before you are aware of it.
Try to understand the product. You should spend more time to understand the product features and flow instead of staring at single ugly code fragments. Understanding it will reveal some structure in the code, even if it isn't explicit. Try to engage your peers about things you don't understand. They will potentially deliver tons of detail and background information. Over time you can mentally map this high level information to the codebase.
If you understand the product better, I'd suggest to write a few (1-5) simple selenium tests that cover the core tasks of the product. This test is simply to ensure that you do not break something on the greater scale and the product is still delivering it's basic value. If you start to find confidence with you tests, you can share them with your peers. This will give everyone some instant value and potentially a lot of respect towards you.
You seem to be afraid of your colleague. You don't even know if he wrote all that code, you don't know about his stance on the codebase. Engage him, try to find out how he is working with the codebase. Try to find out his skill level and mentality. Do not judge early, don't complain. Even if he is low skilled, he could have a lot of knowledge about the product and the company.
Eventually don't expect to rewrite the whole codebase. Rewriting a large valuable project which is in production will take easily a year. One year after that someone will claim this is legacy. It won't help. It is easy to think that you can do better, but even a clean codebase can be a huge mess. Figure out how to gradually improve the project alongside features. Figure out risks and high friction tasks for devs, operations and users.