It is like a gynecologist wanted only to work with beautiful and healthy vaginas. The beauty of this job is to improve whatever you got to work with. If it is ugly spaghetti? First understand it and embrace it. Then try to improve it best to your ability.
Ask HN: Codebase at my work is a complete mess, what should I do?
261–270 of 346 posts
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#262Earlier quoted context omitted.
> Being able to read and work effectively in legacy code is an essential skill for any software engineer. This is key advise. It makes the difference between a person who enjoys the art of coding and a professional who get paid for work. Basically you have to first proof why the invest of rewriting brings any financial benefit. Till then, be professional and maintain it.
Just to offer a different opinion here: I think happiness at work is the most important thing for me personally, and I have no patience for legacy codebases that look like shit. I mean, you are offering good advice for a person that wants to fit in as his highest priority, no doubt about that. But there are people (like me) who don't enjoy working deep down in complicated shitty code to the degree that I don't even w…
People can make their own decisions about this, yes. But an important point I love seeing in a top comment is that almost always it's hard to inherit someone else's code. It almost always looks bad at first. I'm more of a manager than a coder but I've worked a lot of small places and I can tell you, every coder who has worked for me has tried hard to keep code clean, and every coder who's replaced those coders has thought the code was a mess. The only time this didn't happen was when there was really a team of coders working together. Any single coder is almost always going to produce code that looks messy to anyone else. You can say you're not going to work on code like that, but in my experience you're also choosing, in that case, never to work for a small place.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#263Earlier quoted context omitted.
Are you saying you don’t change underwear often? ;)
Not every few hours and I’ve seen people quit a job between starting late on the first day and an early lunch break. So literally faster than I usually change my underwear.
These people should have asked to see a sample of what they were going to have to work on.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#264I'd suggest a two-stage process:
(0) Learn how they do things there, and why, and gain the respect of your coworkers by getting really good at it. You won't find you can make much progress along any axis without people perceiving you as already being successful.
(1) Write all the unit tests you possibly can for as much of the codebase as you possibly can, and try and get the rest of the team onboard with a solid testing philosophy. Extoll designing for testing and testability.
(2) Use these to confidently move through the codebase and replace portions as necessary.
This is the 'replacing the engine while the car is on the freeway' approach.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#265> I started "repairing" the project but there're no tests to check whether my adjustments are correct. I'm so frustrated and depressed by it. If you were to apply TDD to this, you would begin by writing a test verifying existing code, then you will piece-by-piece rewrite it and use your tests to make sure you didn't break stuff.
This. Don't change the code until you have reasonable test coverage. Only changes to enable testing should be allowed.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#266Here'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 there's no testing culture it's pretty hard to introduce it into a team that doesn't have it (either by choice or omission). It gets even worse if your teammates don't update tests (thus break CI) on code changes or just comment the tests out. I've seen both happening way too often and would recommend getting at least some sort of team buy-in - as the alternative will surely burn you out sooner or later.
I've actually seen it done within a large organization. It takes one boyscout who's respected and can clearly demonstrate the value provided by testing and designing for testability, and people will fall in line. Nobody likes building on quicksand, so show them what concrete looks like.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#267Earlier quoted context omitted.
I agree here, but keep copious notes. I've found mind mapping software, like freemind is good for this. It will help keep you sane. Without that, IMO trying to internalize large amounts of badly written code can negatively affect your brain's ability to come up with good, well written code. All those bad ideas and patterns become the first things that pop into your mind when you try and solve problems. “When you star…
Do you have any example of how you use mind mapping. I've tried a few times to use it but have yet to find a good way to layout my notes/thoughts in a map.
I don't have any hard and fast rules, but if it is a big complicated project I don't usually try and come up with a single coherent diagram of my thoughts. Instead, I start out with a node for the date, and a child node for a subject, and child node of that with a sentence or two concerning a topic I'm working on. If there are more details to it, problems, questions, etc. they become sub-nodes of that, and so on.
I don't usually change the details of nodes that I already worked on, but rather write what has changed in a new node with the same name but under a later date node. I find that it becomes a mess if I try and keep every node updated to what I currently think about it, because too much information builds up to efficiently do so. Also, a lot of what I write only make sense in the context of what I wrote on other subjects during the same time period, so if I change one, I end up having to rewrite more and more, which eventually becomes a big mess.
The main benefit is that I can go through my notes quickly, skipping minutia of topics I'm not interested in simply by not reading the details of a node. I used to use a text file, and that was a very big problem, because not only would the amount of text that I'd have to go through became daunting. Also, I sometimes found it hard to interpret what I wrote, which means I wouldn't know if it applied to the problem I was working on or not.
However, in contrast to the above, I do try and make a definitive structure if it's a small topic or a quick idea for a new project or something simple like vacation plans.
BTW, it also works very well for taking notes for a class or self-study.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#268Earlier quoted context omitted.
Not every few hours and I’ve seen people quit a job between starting late on the first day and an early lunch break. So literally faster than I usually change my underwear.
These people should have asked to see a sample of what they were going to have to work on.
They didn’t even have a look at the code. Their task would have been to write and maintain end-user documentation and they left before they even had computer and stuff set up. Just never came back from lunch. Said they’d not feel up to the task. I was just a student at that time, so I can’t really say if that was a hiring fuckup or just an odd person. Certainly one of the weirder things to witness in my career.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#269I started working on a huge, 10yo50 developers with framework version from 2013. Now it is ~300K(unused code removed, some parts moved outside+rewritten), framework is the latest version etc., this was done due to a very good leader with a vision. Nothing prevents you from becoming that person that fixed that infamous project.
It is ok to complain about code quality, as far as you are doing something to improve it. Don't ever complain about a previous engineer, they might have been just implementing the sh*t product was enforcing on them or company asked an inexperienced engineering to glue together this project. It is rarely that a developer knowingly and happily writes bad code. Try to improve it, it will move you towards becoming a senior sooner, nothing helps you in understand how to code more than how-not-to examples. :) Also +1 to do-not-refactor-immediately comments here, observe the project and company and write tests until you know the project and culture well enough, then either increase refactor speed thanks to your tests or separate the project into chunk as micro-services or utility libraries/modules.
Also run static analysis on the codebase, you will be amazed how much "foo defined but never used" cases there will be, remove them completely, have a close eye on production errors when you release them and role-back on smallest of suspicion something is wrong. invesitage, fix, release and repeat. :)
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#270One thing I haven't seen mentioned is drawing a graph of dependencies using Graphviz. It's immensely useful for my current task - removal of two obsolete, fundamental variables from a convoluted permission system spanning a very big project. As a bonus, managers love it because it offers visual feedback.
Normally, unit tests would be the solution, but my ticket spans more than 10 modules (files), some of them suffering from the God Class syndrome. It's infeasible for 1 person with only moderate experience in unit tests to write enough tests before he's fired for not showing results. But it made me realize how important having unit tests in place is, and I made a resolution to write them for my future tickets spanning a single module.
Graphviz uses a super simple DOT notation that is perhaps best explained through showing the gallery. If you click on a graph image, it takes you directly to the source. https://www.graphviz.org/gallery/
With a big enough graph, GUI tools like Dia or Astah.net just don't cut it anymore. Graphviz lets you focus on the only thing you care about - content, and the visualization algorithm takes care of positioning. Because the format is a text file, it's a very good fit for git, you can attach a modified graph to each git commit.
Graphviz is also a great fit for vim. For example, to color all edges leading to particular node, you can type:
:%s/-> ParticularNode/-> ParticularNode [color=red]/gc
Or you can manipulate lists of nodes or edges with VISUAL LINE select mode and type :sort. Lots of possibilities. It's easy to extend a graph copying and pasting modules (subgraphs with cluster_ prefix ) or anything else, and it supports attribute inheritance so you can cut down on redundant lines. Just declare a node style, for example:
node [label="update"] update0; update1; update2; update3; update4; node [label="create"] create0; create1; create2; create3; node [label="\N"] // this resets node labels to default behavior
This way you can have the cookie and eat it. All methods of endpoints are uniformly named, but it's not ambiguous which one is which.
And the kicker - graphviz was initially developed by AT&T, so you have a BIG NAME to back up your tool choice.