this post was submitted on 07 Jun 2024
21 points (88.9% liked)
Experienced Devs
4006 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Depends on what I want or need to "understand".
I've worked for many years on a project (it's a whole project ecosystem tbh with multiple projects; desktop winforms app, server app, SQL server, asp.net MVC app, asp.net blazor app, mobile wpf app, sync service app). On the main project (client + server) I haven't visited one major area, and another I confidently know that it's not understandable to me without specific deep effort.
I recently had to work on the latter. I take a localized approach. Explore what I have to do, without opening the full scoped understanding that'd lead me to architecture refacs. I write out the method call stacks to get an overview of who calls what when. To then know what I have to inspect and analyze further.
I take notes where necessary, or improve and comment code where appropriate for better understanding and obviousness.
I create documentation - about concepts and architecture as appropriate and necessary.
Code should be obvious and intuitive. Concept docs should document the broader concepts.
When those concept docs exist, those are what you look at to understand app intention and behavior. And it should give you an introduction to architecture. From there, exploring the code should be self-explanatory (but may require specific, repeated, and iterative analysis). And I take notes about what's relevant and I need for understanding or task.
Afterwards, those notes should have, or should then integrate into the code base or docs, or be determined irrelevant for that. If I had to write them out and down, it's more likely they should be part of something than not.