Are there tons of global variables?
I can't imagine why he thought that was a good idea.
61–70 of 346 posts
Are there tons of global variables?
I can't imagine why he thought that was a good idea.
There's a book called "Working Effectively with Legacy Code" by Michael C. Feathers which I heartily recommend. I got it a while back when working on a similar sounding codebase and it was very useful. It's got chapter headings like "My Application Has No Structure" and "I'm Changing the Same Code All Over the Place". If your company has a books budget get them to buy it, but I'd personally drop the £35 it costs on a…
> I started "repairing" the project
Don't. Unless your immediate supervisor requests you to do the repairs. These type of efforts largely go un-noticed or un-rewarded, and only cause you stress because you care a lot about the work and the codebase. Sometimes, you even get punished for trying to do the repairs.
> I'm so frustrated and depressed by it
I know it's hard, but try not to take it to heart. There's a life outside of work, and don't neglect that at the cost of your work ethics. Have to leave you with this quote from https://workplace.stackexchange.com/a/83319/12527
> There is an incredibly rich world out there outside of work, and my sense is that all too many people get caught up in what happens within the office walls, at the expense of simply being, living in, discovering and enjoying this world. There have been some interesting survey studies of people on their death beds, and what they wish they had done more of when they were younger and healthier. Hardly anyone says "I wish I had spent more time in the office." I keep this in mind every day on my way to work, and it helps me keep my internal compass focused on the things that really matter, so that I don't regret not dedicating enough of myself to non-work-related pursuits years from now, when it may be too late.
RELATED: Try to achieve the 'Zen-like' state that the dude in office space gets into, when he get hynotized and does't snap out of it. https://www.youtube.com/watch?v=Dp7EUUVdrt0
Even if you're wrapping the entire application.
We're not looking for "does this code do the right thing", just "does this code do the same thing" (as the initial code).
At which point you'll at least have some more confidence that you aren't damaging the codebase due to having not understood a part of it.
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…
This seems like a great post to vent a little bit. I'm definitely a bit touchy on this subject. I like to think I'm pretty good at programming, development, and generally architecting solutions. I don't have a lot of experience, but I have a bit of talent and spent a lot of free time learning. Solving problems with computers is something I'm passionate about. I started this particular project without any idea of what…
that's assuming the original authors used version control, committed often enough to leave meaningful commit messages, and bothered to explain their decisions.
pretty much every code base i've taken over in my current role have consisted of a single posting commit with zero documentation.
I am a senior dev managing a large and relatively messy codebase. Let's see if the way I read the situation checks out: > I've already made some comments about rewriting it and the response was basically "ok". This means that the person in charge of the code is probably aware of its shortcomings. > The person in charge of this project was working on it alone This suggests that probably the codebase started out in a n…
I agree, but it's fraught with risk, and could also turn into an opportunity to spend several months or even years being miserable, and thought a mediocre to poor developer because you aren't able to deliver fast enough. This becomes especially true when the original developer is there and can probably do things 10x faster (which will make you look bad).
You'll need to make sure you're having regular one on ones and keeping your team lead/manager up to date on the work you're doing. Perception is more important than anything. If you save the world but do it quietly, nobody will know, and they'll decide you aren't productive enough.
1. Stop "repairing" it because you're guaranteed to introduce bugs and regressions. You haven't learned it well enough and can already sense the fragility, which is why you're anxious. 2. Relate your impressions to the person in charge: "The code doesn't seem to follow best practice and appears fragile. You think there may be technical debt that needs to be addressed sooner than later." 3. Until you're confident enou…
Yep, because I have worked with very bad codebases over the past 25 years, I actually enjoy the challenge. For me it is more rewarding than working with pristine and well managed code bases.