Not a direct answer : I’m quite shocked to see most people answering that they just plainly read code or go debugging right away. It might work on small projects, but definitely not on bigger ones.
I’m currently working for a company on a huge, messy codebase about 20 years old, and I think these 2 methods should really only be used as a last resort. When dealing with thousands of files, you have to develop rigorous strategies to navigate through the codebase.
What you should do in my opinion, is rather to read related tests if your application is correctly structured and covered, or understand the domain and use full text searches for precise functional keywords, or make good use of execution traces such as logs to pinpoint the entrypoints used by the actions you wish to modify.
We actually train junior devs, during our onboarding process, to quickly identify code by teaching them our architecture, frameworks, and practices.
I once found issues with an open source library I was using in my code. At first you think it’s your own code. It’s quite surprising when you find bugs in code you don’t maintain.
To find the issue I had used a debugger. Basically you put down breakpoints that pause execution of the code and allow you to explore. You can run the next line of code one at a time and see all the variables that exist and their values while debugging. This can be very useful while trying to track down a confusing error.
Most of my work involves web applications using a pattern called MVC (Model, View, controller). When this design pattern is used, most of the time a similar folder/file structure is followed. For example if the page needs changed to display something in a different color, then you usually just need to find the correct view file in the view folder. So you might start by noting the address of the page you’re changing and find the controller that renders the view for that address. It’s always a case of following a breadcrumb trail.
Hope that sheds some light on the subject!
Not really a programmer, but I have contributed code to an open source project. As others have said, refer to documentation to get as much info as possible. Usually this will also include contact info for maintainers, so you a can reach out to ask questions that way (forum, email, discord, etc). Just be patient as a lot of maintainers are volunteering their time.
We don’t… text searcher does 😛
On a serious note, most programming languages and practices follow common logic and “traditions”
A little example would be illuminating 🙂
A common programming structure is called MVC – Model View Controller
Basically you keep a structure that separates code to 3 parts
* Model is what goes in the background, communicates with the database and does tasks given by the controller
* View is what user sees or things that display data given by the controller
* Controlles is the “brain” which knows what to do when to do, gives tasks to the model and gives the results to view
If i would go in to a project i know nothing about and i want to “upgrade” an input field on the form
I would look up how the imput is called, I look for that name in the view files. Next look at how that particular part is controlled and get the model from which the data is loaded and/or saved.
If i have all 3 parts i could modify the behaviour of that input, how it looks, what id does, how it is saved
—
This is a gross oversimplificatoin, but this a jist of it.
Usually programmers familiarize themselves with the projects they want to edit, so they always have a vague sense, where to go is something is broken or needs to be upgraded.
As for errors, programming IDEs and error logs usually give you the exact location where the program “stopped”
Latest Answers