Watch the talk version on The Monthly Dev
Whether it's contributing to open source or starting a new job, the first step is familiarizing yourself...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Love the tips, thanks Abbey! Every time I have to deal with a new codebase, my first PR is to improve the README file. I read it completely first, then try everything that's on it to get the project up and running. I add to the README file every extra step I had to discover from colleagues (or the internet) and then send my first PR 😄
Number four is super important. I've been fortunate to be in work environments for most of my working life where asking questions is encouraged. Even then, some folks may have negative feelings about reaching out for help. However, sometimes the quickest way to deal with something is to get some support.
As far as number two goes, one key thing is to check the log output. If the app doesn't have logs there's not much you can do other than black box testing to try and understand how it works. Absence of logging compounded with spaghetti code can be extremely difficult to unravel and at that point you're going to have to start taking notes or drawing diagrams. One thing I like to advocate for now is better logging even on personal projects of friends. It makes life way easier for yourself and others if you've got good logging habits.
100% - I've been in environments where questions weren't encouraged, and some of my advice from that experience made it into the guide I linked. I've noticed that if you frame it as a technical problem and list all the things you've tried, there's usually at least one dev who wants to solve the puzzle.
It's interesting you say that about logs! I've been in environments where there was no logging and so much logging it's difficult to find the relevant ones. I guess as a result, I am always taking notes and drawing diagrams. 🤣
"Feed the app bad data. I dare you." - Favorite line.
I'll be saving this for later
My Aug 23 post is not meant to be hidden ... think maybe it's too long to show here. When I click on the date the post comes up in a new page; don't know if it will if you're not the author.
The post suggests using AI (ChatGPT for me) to help analyze, document, and understand a new codebase. The long post length is due to including ChatGPT's response to a list of steps to follow to deal with the limited 'token' count for each input to ChatGPT.
Thanks for this article and for featuring the Lion King on the cover image ! 😁
Another tool for making diagrams : Draw.io ; free software, light, available on the browser or with a desktop app, and many integrations with common tools (Atlassian Confluence or MediaWiki for example).
If you make a diagram to understand a new code base, don't miss the opportunity to share it !
I’m surprised no one mentioned the obvious modern tool: AI. Here’s a discussion about using ChatGPT to analyze a complex-sounding multi-API codebase; I found it very enlightening:
mentorcruise.com/blog/empowering-c...
Here is ChatGPT’s response to my list of suggested steps, recognizing there a limit to the number of ‘tokens’ (4096 words, symbols, etc.) that can be input to ChatGPT at one time.
******* ChatGPT response
Your approach is methodical and well-structured, making it effective for understanding and dissecting a new codebase. Let's delve deeper into each point:
Share the context (what the code does):
Share and analyze the entry point code (where the code starts when it's run):
Analyze where the opening code 'goes', and what triggers that action:
Then analyze deeper and further down the paths of action and triggers:
Additional Suggestions:
Tests: If the codebase has associated tests (unit tests, integration tests, etc.), analyzing them can give insights into expected behaviors, edge cases, and usage patterns.
Comments and Documentation: While code should ideally be self-explanatory, comments and documentation can offer additional clarity. Sometimes, the reason why something was coded in a particular way is more important than the actual implementation, and comments can shed light on that.
Refactor if Needed: As you go deeper into the code and understand it, take notes on areas that seem overly complex or confusing. After discussing with stakeholders, consider refactoring these areas to improve clarity and maintainability.
Your approach provides a systematic way to navigate, understand, and possibly improve a codebase. Remember that understanding a new codebase is often an iterative process; as you gain familiarity, you might revisit earlier steps with new insights.
This is Great!!
One more thing which we can do is, Analyzing other developer's commits and trying to understand their code.(also we can ask them if got confuse)
Some commit messages aren't great at all lol.
That's great for a beginner like me, thank you. A beginner question: are there codebases that are 'meant' to be run only on cloud services, AWS for example (which I know nothing about)? Or the company will always have a 'local' codebase for testing and such?
In my experience, unless you're working on the application that is run in the cloud, there are usually environments always running for local development and testing (dev/develop and QA).
If there aren't continually running environments, I would be surprised if you were expected to stand up a cloud VM (virtual machine) without any instructions. In addition to costing money, there are typically enough permissions and authorization steps required that setting it up is documented somewhere. If it's not documented, there is usually the expectation that someone will have to help you get set up. After the VM is created, running the application in it is the same as described in step 2.
For something like a Docker container, you would have to learn the basics of the tool, but I'd also expect to be told what packages to install and where to pull the image from. Often, there's a configuration file similar to a manifest file with that information (for Docker it's compose.yaml). There also may be authorization steps and scripts for refreshing the data, just like a migration script for a database.
Thank you for a very detailed answer. It helped a lot!
EDIT: my question was hypothetical. Obviously, if I'm new in a company, I wouldn't have lied in the interview and would have been honest about having no experience in cloud computing. So, if I got hired sill, they'd know that!
😅 Not hypothetically, I was upfront about being fresh out of bootcamp with no cloud experience and still got put in charge of several VMs. One time I basically locked myself out of one and my sr dev had to help me stand it back up. Developers are often expected to learn new tools on the fly, so it was a good question.
suppose i am working on a project some of technology i don't know and there are bug on that part then how can i handle that
can you make on specific for open source
Here is the really cool book dedicated to that whole topic, titled "Object-Oriented Reengineering Patterns"
oorp.github.io/
Thanks for the tips! I'll be sure to apply them when the time comes : )
This was helpful, thanks!
Break it and Then fixed it is superb .