How do we work on someone else code, like to implement a new feature
Hello, quick question, I'm currently doing an internship. Last year also I did an internship where I needed to build something, it was pretty interesting. But this year, what happens is that I was put directly in a team to work on leftover works in their backlog (very boring tasks). Even though it was boring, what I noticed is that the codes have been written by many devs and it rarely happen that we work on something from scratch.
So my question is, say I need to understand the code of what developers did, how do I do that? I mean for example, I started to debug things, I understood what's happening on a high level but there are still things that I feel without knowing what was done initially, from scratch, it's a bit to add/implement something.
So I wanted some ideas on how you guys do when you need to implement some codes in a software that wasn't written by yourself, it's kind of annoying, right? But I do realise that this is what's going to happen when I will work on full time job, just wanted some advice on how to tackle/exit out of this scenarios.
26 Replies
i inherited a project with over 1800 php files, and most files have 3 classes thst inherit from classes thst inherit from others
but i would start by trying to make a glossary of what means what
then try to find patterns in the code, while working on it
and if it has debug features, make use of them
oh ok, so you take side notes?
You usually don't need to understand the entire code base. You only need to understand the part related to what you are doing. If the code is well written, there should be some implementation of the principle of "separtion of concerns" and "single responsibility". In that case, you would look for code related to what you are going to work on and only examine that part of the code base.
If the code is poorly written, there are no tricks to help and even a highly experienced professional will struggle to deal with it.
yep I see, thanks !
yup, on a badly distributed code base, that is how it will be
you will have to find out what does what
again, if there are debugging features or any extra information you can get, take it
if it is a website, a simple trick is to find the code by classes or ids in the html
or anything you can easily identify
like a comment, a tag, a bit of js, a name ... anything
If the code is well written…Tell me you've never worked on real code before without telling me you've never workd on real code before 🤣
I used "if".
(also, lo-key: yeah, working on other people's code is just suffering, especially at the start. It gets better the more familiar you get with someone else's code and style)
With bigger/midsize opensource projects they usually have guidelines you should read.
same at companies, but the documents will usually be at least 4 years out of date and not very good to begin with because they were written by the one guy who went to a convention that had a talk about this stuff and made it his slacking-off-project he could dump hours into on his timesheet and then had to rush to finish when his manager wondered why he had 140 hours of work on something he'd never seen
yeah, where I'm working, the docs are from 2017 😭
I have another friend working there, how is also an intern, there, one of the dev/senior dev told him to remove all comments he inserted, don't know the reason though but it's strange
We're they documentation comments?
nope, simple comments I guess
like:
comments are a double-edged sword sometimes. Some folks consider them an anti-pattern, though most people still think comments can be important. The idea is that code shouldn't need comments, because it's more important to write legible code that's easy to reason about. Adding comments would obfuscate the code, and perhaps even put the next dev on the wrong foot. Also, over time, quick fixes sometimes get applied to code without comments getting updated, which means comments can also just be wrong
removing them altogether is a hell of a way to solve that problem though, way too extreme
oh I see
it's like cutting off your foot cause you stubbed your toe
yep I see, I swear, in the corporate world, writing code is not the hardest thing but the "good" practices that need to be follow are 😭
In English we have a phrase: "Cutting off your own nose to spite your face"
especially cause those shift quicker than projects die, and are heavily opinion based anyway
I knew there was something 😄
yep I see, thanks !! won't bother about that, will just follow what comes in different organisation 😂
code shouldnt need comments, but how else will you know why i did
value = 1 + ~value if i dont leave a comment?
some comments are importantyeah, that's my stance too, really. If I'm like... "wtf is this even" when I'm writing, I'll comment or refactor. Or add comments about business reasons.
another one:
array.prototype.sort does some funkery and i found a case where the this would be set to null, so, i had to .bind(this)
if i dont write a comment explaining that, nobody will know why that's there
one good explanation i heard from somewhere is:
comments shouldnt say what, but explain why
useless comments like //this is a return are absolutely useless, and explain what the code is, not why you are returning just the 5th array value
or the expectations
but in the end, it explains the why
and that is a good comment worth keeping
Learning how to navigate and deal with a large code base is one of the most important skills of a software dev in my opinion. School doesn't prepare you for this. You always just write small little things where you know what every line does. But on the job that is almost never the case. Some practical tips i'd give you:
- Learn your ide navigation well. Learn how to jump to declaration, see all uses of that function / class, and where variables get written and read from. Jetbrains ides have incredible tooling for that but whatever tool you use is gonna have something for that. Very important to learn navigating!
- Use multi row tabs. Many ides by default only have a single row. I often find myself with 3+ rows of tabs open when debugging. Vertical tabs can also be good. Whatever you prefer
- Use bookmarks. VS and jetbrains have bookmarks that let you mark lines and assign names to them. In super messy codebases this is useful to remember where the important functions are for what you're working on
- Don't understand everything. Only learn a function if you need to. When I look at a new function I just gloss over it and try to understand the general intent. Identify what the inputs and outputs are. What are the arguments? Does it use global state? Does it modify global state? What does it return? Other side effects? Everything other than that is just an implementation detail and not important at first until you have to modify it
- Use breakpoints to understand control flow. It's sometimes difficult to understand where a function is being called from. In that case set a breakpoint until you get the call you expected. That makes it easier to backtrack the call stack and get a sense of what the app is doing
Only once have i drawn an actual diagram to try and understand what the code is doing but that was all ai generated garbage with type errors that didn't even work properly, so no wonder i couldn't understand what it was doing. It was straight up broken :P
But yeah you can draw diagrams if you want but the issue is those get outdated immediately. If you can keep these connections in your head it's gonna massively help you in the long run
The thing about considering the inputs and outputs of a function is something you should keep in mind when writing code too
Also don't let boring bugfixing tasks discourage you! They're actually a great way to learn a codebase and on the job at first you're likely also just going to fix a few low hanging fruit bugs just to get aquainted with the project. If you're doing nothing but bugfixing for months that can be gruelling though I agree. Just came from > 1 month of nothing but bugfixing myself because everyone else was on summer vacation. But it's just part of the process and it can be really satisfying to just get rid of all the annoying little bugs
yep I see, thanks !