How Do I Understand a Complex Codebase At Work?
2024 ж. 5 Мам.
40 773 Рет қаралды
I just started at a new company. How do I learn to work with their code? How do I get up to speed on the code I have to work on? What if it is complicated, spaghetti code with no code comments? How do I learn to support it? These are the questions we are going to answer in today's episode of Dev Questions.
Website: iamtimcorey.com/
Patreon: / iamtimcorey
Ask Your Question: suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimcorey.com/
1. Start reading the code 2. Plunge into a black hole of despair and self doubt from which there seems no return 3. Sleep all day after work 4. Start doing a task which forces you to really care about a specific part of the code base 5. Before you know it, the codebase starts becoming familiar
lol
Step 2 is so true 😊
Glad I’m not the only one😅
@1:21 Read available documentation. @1:41 Talk to existing developers (and take notes): Document what they say. Don't ask them the same question twice. @2:42 Read unit tests (if available). @3:11 What if there are no documentation, no advising devs, and no unit tests? @4:00 Procure a development environment from boss; try to make changes, build it, deploy it, and learn. @4:51 Step through the code using breakpoints. @6:13 Write unit tests to aid your understanding of code. @7:44 Document everything you learn, update documentation and share it to get feedback (helpful to you when you forget, or the next person who needs to be onboarded; use videos, code examples, etc.). @8:46 This takes to much time! It's extra overhead but it makes the process of debugging/troubleshooting more effective and it helps others get up to speed.
Would like to add that when taking notes, ask to download a video-recording app (OBS Studios, etc.). Create tutorials for doing stuff. Also, apply what you know about UML to create diagrams and make your notes engaging and useful (i.e., reference specific lines of code/methods that you found confusing)
1) No proper documentation, no one bothers to document the difficult part of the code; 2) Developer who are willing to help are snowed under work that makes you not bother asking them because of that as they're pressured to deliver. Developers who are seniors and have time have the 'don't bother me' attitude and are not interested for mentoring; 3) There are no unit tests, imagine that? Well, it's because it's a 20 year old code and the system is so difficult to simulate piece by piece by unit test, so the only way is to run the whole system and debug from there, like a hit and miss kinda thing;
Another thing that can be done, perhaps before starting a breakpoint-heavy debug session, is to run the program and read the logging statements that are produced, if any. One may need to switch to debug-level logging in the logging configuration file to get a good idea what's going on. Of course, if logging exists, then there should also be log files from production, which one also can have a look at.
Yep, good points.
Logging vs debugging: logging allows you to see what has happened days, weeks or months ago. Debugging is only good if you have the inputs to reproduce the problem. Not enough people understand the value of good logging. Use a verbosity level or similar to control how much data is sent to your log. Turn it to 9 when there may be a problem and lower when the kinks are all worked out.
Logging also allows you to keep good notes of a specific problem you may run to in a project or ticket.
This has been helpful. I am in this exact situation with 0 out of 3. There's a huge code base with no documentation (Senior Dev believed that "Self Documenting" code was enough, and if you didn't understand something then you just weren't smart enough.), all the senior devs either left or were laid off (combination of Covid and pay disagreements), and there were no Unit Tests to speak of (Senior dev said he moved too fast to waste time with Unit tests). I've pretty much been doing all the stuff in this video. I've personally got the most value out of documenting everything. It leaves a reference for me to use later, and my team finds it helpful. I have also learned a lot, because while my senior dev was an ass-hat, he was also a coding genius (coding since he was a child, and his father was a computer science professor). I pretty much come across something every other day that I don't understand and have to research. With as much as I've learned, I feel like I'll be dangerous at my next job!
Those lessons are hard, but they do really improve your skills.
This is awesome! Not bad to wish myself this luck wrapped up in what's seemingly a huge challenge. Nice one @seporokey
Same here! The project is also in a completely new language for me (c++/Qt) but after 2 months of daily struggle, now I feel like I have superpowers 😊 I still have to learn to write proper unit tests though, it'a very good tip!
Do we work together haha? I have a similar "senior" dev.
Hey there!, Did you also work on the code base outside work hours?
Great, insightful and very helpful! Thank you Tim. This will surely help me on my adventures.
You are welcome.
This is quite helpful. I have to do stuff like this all the time as I frequently get passed along applications that are usually a wpf app where all the code is written in a 100k+ line file, no documentation, comments, previous workers, and no co-workers.
Glad it was helpful!
I recently started a new job that is in an ASP environment that has a very very complex code base. The software itself is complex. I have been struggling to offer support for this application because I’m learning from the code base instead of actually playing with the software due to clients that are not hosted. Once again you have exactly what I need Tim. Thank you so much.
I am glad it was helpful.
Excellent as usual, Tim. Thank you for this. So appropriate to my current situation. :)
You are welcome.
Super interesting and useful, so I leave a comment to help you out in return. (I guess it works that way ?) Thanks Tim, I've recently discovered your channel, (I am currently trying to learn C# in my new job) and I love it !
Yep, that does help. Thanks!
Hi Tim You sure put a lot of work into helping the community. Cheers Oliver
Thank you. It does take a lot of work.
Very well said, thanks so much for sharing this advice!
You are welcome.
Been there... there now... I wondered what you would suggest. Very good. I think you might want to expand that when you say documentation, that can mean just start writing comments in the code. That has helped me in the past. Right now I need to get up to speed with Mongo... There is a fair amount of documentation but it isn't what I need. By the way, you say over and over that a person can't just watch videos and read about coding, they have to do code. I'm trying to persuade a young lady at work of that and she is a fan of yours, but I don't think I have convinced her even with pointing out that you repeat that in just about every video you make.
Great suggestion, thank you!
You are welcome.
I remember a site I was working on where I volunteered to do programming work for that was written in PHP. I wanted a VM with a working copy to learn the code. What I got instead was they sent me some spaghetti code that had multiple hard dependencies in it that I couldn't even get to run and they said there might be bugs in it. They wanted new features and I couldn't even get a working system to start with. After that I looked into something to try and help me understand where to go in the future and I read Working with Legacy Code (great book with some good ideas on where to focus your time, like decoupling dependencies and introducing unit tests).
That sounds messy.
This is super helpful, thank you Tim
You are welcome.
thanks a lot Tim.
You are welcome.
Thanks you for sharing your pro tips
You are welcome.
Writing unit tests in order to understand is great. It helps you to understand not just what the code does, but also what it is supposed to do. Sometimes a piece of code does something other than what the intention was, and bringing that under the attention of the one responsible for writing that code can lead to some insightful conversations. Even if it does what it is supposed to do, but you have no idea why (you can understand the code, but not the purpose) this is a great question to take to the other developers in order gain insight into the thought process behind the code and the general way of thinking that is assumed but not made explicit.
Agreed.
I've inherited so many large code bases in so many languages. One thing that I always try to do is realise what initial framework wizard was used to get the project started, run that wizard myself and to spend a few days bolting on simple features. If you have spent 80% plus of your career working in one language/ framework then this may seem like a waste of time. But for me going from the MFC scribble tutorial to Java camel, Xaml MVVM or a new state machine, the moment you step back from your wizard project and recognise the same project organisation in the huge legacy code base can be a moment of quiet satisfaction.
Thanks for sharing!
Excellent !
Thanks!
Please guys, when you finish a Story/bug/task what ever, always write a documentation that a "non developer" could read and understand
Good suggestion.
Step 2 at 6:06 timeline is to keep an eye on console if application runs on local. Check the classes that got eagerly loaded.
The code base I work with all the Devs left; they are using entity Framework and dapper to call stored procedure. While I was writing unit test, I found that none the stored procedure was present so I had to hunt down for 2 months to locate those.
That can be tough.
That’s good one thank you!
You are welcome.
Thankyou. Your a new "Pragmatic Star". So many are misleading the young.
You are welcome.
Oh the luxury of having a codebase at all. My first task in one contract was to decompile a system in .net 4 that kind of worked but the code had been lost then rewrite it properly in .net 5. That was fun.
I can imagine. The only real bright side there is that you were able to analyze the inputs and outputs and come up with a new way of doing things rather than trying to force old code to do new things. Small comfort, though, when it is a complex system.
@@IAmTimCorey first step was as you suggested, write unit tests see what it should do find the bugs andthen fix them with the appropriate improvements added in for the newer language features, then it was onto refactoring the code to male it maintainable which was also facilitated by having unit tests and also a few integration tests. My clients now have a good example of how to organise a complex piece of functionality to make it easier to read which is also testable and I have repeat business doing their impossible projects.
Where I'm at right now.. fucking hell
this video is interesting and a little bit different from its subject because it is mostly about how u can make the code understandable for future new comers and ! thank u Tim , by the way i have a question, when is the right time to write unit test , does it make sence to write unit test with a not complete and stable project ? because u may change codes alot and therefore u should also change unit test too.
At the unit level, you should be writing finished code. Meaning, if you write a method to do something, it shouldn't be continually changing. If it is, you have probably not done a good enough job planning. So while the overall logic might not be stable (it probably should be pretty stable), your units of work should be.
Tim so what is your take on the latest MS Office Zero Day Exploit targeting the MS Diagnostic Tool?
1. Read the doc if available: Which part is important which is slow 2. Ask a senior dev: Write down in a notepad what they say. Often they get frustrated when we keep coming back with the same question. So, don't go to ppl again and again with the same question rather go to the doc again and again. They will see you are wanting to learn and grow. 3. Look for Unit tests in the project. If they do, what do they do? These tests will tell you how specific methods are supposed to work. 4. If 0/first 3 points => Get your own development env. Me to boss: I am new. I am gonna mess things. Help me help you. Let's test things w/o breaking real things. In dev env I can break things w/o affecting others. Practice making changes in the codebase and test things out. 5. Code flow: Put break-points, make assumptions, make concrete conclusions if code code breaks or code flows. Understand the flow( one time thing ) => Understand what the code is doing. Make notes 6. Start Unit tests. Create small tests and test them with inputs and outputs for specific methods. Argue if the unit test is wrong or the code is wrong. 7. Document everything you learn: Always work along with coding.
Thanks for sharing.
I went from working on micro services into building private cloud with KVM, puppet, kickstart, FreeBSD and everything else. I so miss having breakpoints 😂. The worst is when your Linux or FreeBSD host doesn’t come up after a fresh install. You have no logs you can access.
Yep, that's rough.
This is gold
I am glad you found it valuable.
Understand the business logic as much as possible. That will help you understand the code flow half the speed. Get familiar with the data which the particular piece of code use to understand quicker
Thanks for sharing.
Thanks for the topic, and thanks for sharing your opinion. #unitTestFTW
You are welcome.
Perhaps if we had a tool that could be used to collate all the methods/classes that get called or are involved in accessing say a page in an example .NET MVC Web app, I thought it would help narrow things down in understanding complex and huge code bases? I have recently gotten to know of Microsoft Visual Studio codemap, which I am trying to figure it out - if it could help me with the aforesaid - but does anyone here know of anything that could help in that regard?
read documentation, existing developers worked on it, read unit tests, if not ask boss and work with own environment.
This is me, basically frustrated with the very complex code base which is almost 2 decades old. The documentation doesn't help, and the manager and the PM are expecting me to hit the ground running fixing issues with their on-going project, the manager asked me last week how was I doing, I initially gave him a defeated look, and then told him I will get over the bump on the road, he just told me to please not quit too soon (like what the many devs before me did...). So basically is like having a nose-bleed for me...
That's a tough place to be. Being open in your communication and being clear on what you can do compared to what the expectations are on you will be important.
@@IAmTimCorey Follow up question is, how do you train your brain to understand so much complexity and high level code base? I'm not the only one, seriously. There's a couple of mid-level devs who are almost at their wits end, caught them looking at job Ads and telling me it's frustrating them so much that they are now looking for another role. I guess some people's brain are wired to be a developer on a completely different level, some are mediocre. I think I fall on the latter.
Please we would like more testing videos, Unit,Integration, SpecFlow pleasee and keep going thank you
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
For me Diagrams work, I visualize the execution and link classes and functions and explain myself with Diagram. its way easier because our memory is more visual than textual.
I'm glad they work for you.
Tim, thanks this struggle, please make a project based tutorial how we connect WCF to AWS
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
@@IAmTimCorey thanks
Hi Tim, what's your thoughts on event driven architecture?
It can be a good choice in certain situations.
😢 we are not able to run the software we are working on, wh have an azure pipeline which adds the "secret" dependencies and creates an installer...
That's not a great setup. I would recommend working with your leadership on setting something up to get a local copy working.
Comments are also nice, but whoever inherits my code will hate me. I know there is an ongoing developer joke about self-commenting code. When I write a function that is named GetUserInfo() and the three variables are firstName, lastName, and email. I don't comment that code. Yesterday I was looking over some code that I wanted to integrate into my application. I have been coding in C# and the code I was looking at everything started with function constructor() and the comment was // Constructor. Finally figured out I was looking at JavaScript. So, I don't know where I'm going with this, but when I am trying to figure out how a piece of code works, I do exactly what you mentioned. I view the properties of a button and add a break point at each event. Then I step through or over whatever happens in each method. If the button is titled Save and after several steps ends up in the GetUserInfo() method then a method that takes the three pieces of information and a stored procedure to connect to a database. It might take some backtracking to figure out that the data came from user input and three textboxes and a method with validation code. If there isn't validation code, that is maybe something I need to think about. I really don't trust my users. The best way to learn is to try things out and to try to break something. If you can break it and then fix it; you will learn. disclaimer: My everyday job is not coding. I am only pretending to impersonate a programmer in my free time.
Yep, code comments can be great or they can be awful. I would delete unhelpful comments. Also, comments aren’t the only way to document. Make notes separately and share them with the team.
That's my number one source of stress. Having to implement a feature on some legacy codebase from 20+ years ago. The solution has 130 applications, and im always afraid to open it.
It can be tricky to do well.
Thankfully now we have chatgpt who will read any code in seconds and explain :D
Unfortunately, that doesn’t work for big picture yet. It will explain methods but not systems.
That's my world. I inherited close to a thousand VB6 programs and they were all written by people smart enough to make an insane mess out of every single one of them. My favorite was the guy who had a doctorate in mathematics and I had to fix his function that compared the three build numbers. I could not even tell you what he was trying to do but it did definitely not work. I find it helps to make one of those little voodoo dolls for each legacy coder and have an ample supply of pins at hand.
I'm hugely surprised that #1 wasn't "Sit down, and read through the code.". Most of the code should be human readable, unless highly optimised, and the highly optimised code should be developer-readable. Read the XML documentation, any code comments. Add your own code comments, and XML documentation where needed. Be it a web app, desktop software, mobile app, nuget package, or plugin, you should have an idea of where the entry point to the codebase is. You can read from there to gain an idea of how the code flows. #2 would be to check for common dependencies. If the project uses dependency injection, then where is the container configured? That will be your nexus, where all the features of your codebase come together. What other patterns are being used, and which libraries are being used to implement those patterns? Do you have a mediator, or a plugin framework, or any libraries/packages that you recognise, or have worked with before? It will be far easier to follow them, and see how they are used throughout the project. Then, #3 would be create a Sandbox file, and use it to traverse through the intellisense of the code base. In a pure dev-time setting, with no building, no running of code, you can practice how you will work with the existing code. I work in .NET, so I'd new up a load of classes that sound interesting, using namespaces in intellisense as a guide. Then see what can be done with those classes, just through intellisense alone. My first point of call would definitely not be to launch the code, and change things to see what happens. There is so much you can do before you ever press start.
I'm curious how often you have done something like this with a large codebase. While your #1 sounds great, if they don't have documentation or unit tests (and they probably don't), the code probably won't be that readable. Reading code is a valuable skill, but it isn't always the first way you learn the codebase. The reason why is because the code probably won't be in just a few locations. In order to understand the big picture (which is what you want to start with), you will need to understand the flow through 100+ locations (at the very least). That's a bit much to get when first getting started, especially when you don't know what questions to ask. Also, and this includes #2, most business codebases are hundreds of thousands of lines of code spread out over multiple projects and solutions. Trying to identify all common dependencies will again give you a headache. For instance, I worked at once company that used the GAC to store all of their dependencies. Essentially, you didn't know what depended on what without tracking down each line of code. Others totally missed the boat when it came to dependency injection (a very common occurrence), so again, you didn't get a centralized set of dependencies. Finally, for those who do have centralized dependencies, they are usually per resource, not necessarily for the overall application. That means tracking down dozens of locations and then tracking down locations from those locations in a spiderweb. Your suggestions will definitely have some value and in certain codebases, they will work great. They just aren't as universal as I was going for. Getting a development environment set up and running right away is critical to understanding your application anyway. Doing so and seeing what the application does and how it works through the code will give you a practical hands-on understanding of what really happens in the most efficient manner possible, regardless of codebase size.
@@IAmTimCorey My experience of existing codebases is very minimal, and limited mainly to games development in .NET (non-Unity). The codebase I'm developing for at the moment is hundreds of thousands of lines, if not millions (largely consisting of legacy Java code, copied more or less verbatim into C#), across six main libraries. While I agree that running the application is important, I was just massively surprised that "Read what is on the screen in front of you" didn't come before "Launch the app, and change random stuff to see what happens". I'd consider even just a cursory scan of the code by eye to be due diligence, before building the code. There wasn't even any mention of documentation or code comments within your #1, just straight up pressing play, and pushing buttons to see what falls out. Obviously, if there is nothing at all, no XML documentation, no code comments, no solution guide, no architecture overview, no readme files, no issue tracker, no test suite... then you can only start from "Ok, so what does the app actually do when you start it?". But there's a lot of caveats there before pressing play for the first time. I agree with your points, I just think they are in the wrong order. #4, (Document everything) should be #1, and should be intrinsic to every other step. And part of that is to look for, read, and understand the current documentation, code comments, and solution guides; as well as whether the code is readable enough to comment itself. That way, as you write your unit tests, you can add XML documentation to public members that don't currently have them; and write human readable translations of highly optimised code, as code comments, where needed. This should be a continuous process, from the moment you gain access to the codebase. Discovery, understanding, enhancement. Is the code documented? If so, what does it say, and what does it mean, and how can I make it better for myself, and for others? If not, it does from now on. Once you've established whether the code can be followed by eye or not, then you can press play, and push buttons... labelling each button with a nice little summary, as you go.
How to document properly and with developer standards?
“Properly” is subjective. Write clear code, practice creating simple methods, and then use the triple slash comments to document public methods. Also, create clear commit messages and create unit tests to validate functionality. That should handle the biggest parts.
Would be great if only I had documentation, unit tests, and code comments in each and every project...
That's why I covered what to do if none of those are present. However, as you learn, you should implement those things so that the next person will have them. Doing that will also teach you more about the system.
Currently 2 years into the project and still feeling the codebase is complex. When will this end?
Try 5 years..
When you move somewhere else with a simpler codebase. Complexity wont change but your famiarity with it may improve.
@@maxthecat4632 "simpler codebase" is this even possible in today's world? With new tech and cloud, and the "need" for decoupled systems and architecture, it's becoming more complicated to navigate and work through the code.
@@MrBunny53 yes it is possible, however it unlikely because many programmers I have encountered seem to think that solving simple problems in complicated ways shows how smart they are when in fact it shows how stupid they are.
Complexity is not really a fixed concept. It is dependent on the viewer. For instance, if you asked me if data access with Dapper was complex, I would tell you no. If you asked a new developer the same question, they would probably say yes (it uses generics, asynchronous programming, anonymous objects, etc.) So to answer your question, while your codebase will probably always feel somewhat complex, you will get to a point where it feels comfortable and maybe even not that complex. As your skills grow in it, you will start to understand the reasons behind the choices that were made. You will start to understand the logic of the system as a whole. While you may come across sections where people added needless complexity (and if you find them, remove them if possible), what you will mostly find is that what appears to be needless complexity is often a decent solution to a unique problem.
I actually had a volunteer position where I managed to understand their systems and teach them. However, after doing that, they realized that since they can do the work, it was actually faster for them to actually do it then to explain to me each time what was needed. So its actually very common that once communicate the information, then you are no longer needed in any job. Most bosses find it faster to do it themselves than explain to another person what they want.
That's not how the world works. If that were true, no one would be hiring developers. Right now, if you search Indeed for C# and select "remote" for the location, you come up with 16,000 positions. That's just a fraction of the currently available positions in development (a TON are in-office only and a TON aren't even on Indeed). So no, most bosses don't find it faster to do it themselves unless the employee/volunteer is very slow and/or doesn't do what is asked.
my boss is wearing tshirts saying "the code is the documentation" so..yeah.
😂
It’s even harder when you start working in a new language 😢
Yep.
Reverse engineering, but this time you have the source code :)
Pretty much.
"Step 1: read the documentation". Oh, hi Tim. You must be new here.
Nah, just not assuming failure. Once you start working on the code, you should be documenting so the person after you should be able to pick up at step 1.
meh. hoped to find something new, but, unfortunately, didn't. anyway, this video formalizes all things i used so far. good thing to send friends if they didn't try any of proposed ways of learning the project
I'm glad you at least affirmed what you were doing.
Who has time for all those things he said, these days you have to show progress every day ( thanks agile/kanban etc) . No time for any of the stuff he says unless you want no home life.
If that’s how your company defines agile, they are abusing the term. Agile isn’t about developers working any faster than with waterfall. It is about how they order their work. Agile is about doing small bits of work and then releasing rather than all the project at once. There should still be time for documentation, understanding the code, and more.
Abcd
efg
Hijk
hi
What if the app doesn't even compile lmao
Then you have some work to do figuring it out.
@@IAmTimCorey i got it working i just deleted all the dlls and cs files and imported the prod dlls. Rewriting it using web assembly now
What is this "documentation" thing of which you speak?!?
Sounds like most organizations I've ever worked at.