Working with Existing Code

[00:00:00]
>> Francesca Sadikin: In our exercise, we had the easy example of working with existing code because the requirements were given to us. It's much easier to refactor and do all these codes when we actually know what that code is supposed to do. But in a real company, that's actually the hard part [LAUGH] is like you come into the code and you're like, what does this code do?

[00:00:25]
What's going on? And so, there are little techniques to help you ramp up on what that code is supposed to do. As you saw, I use a debugger to, like, resolve a problem. You can also use the debugger to help you understand from your entry point what that little piece of code does and its relationship to other code.

[00:00:54]
As you saw writing test. So writing test against that system, like giving it lots of different parameters trying to understand Understand what it's doing is also very helpful. And then just a recap of Chester since fence, which is a way of saying don't change code unless you really understand what it's doing, [LAUGH] right?

[00:01:11]
Don't just delete code unless you a 100% sure you know what it's doing.
>> Francesca Sadikin: Okay, clear debugging process, whether you're fixing a code, a bug or you're just trying to understand what's going on. It's important to have a clear process to help you unblock yourself. If you don't have a process as unlike when you get frustrated and you just start like, let me try a bunch of different things, like I do.

[00:01:41]
Let me show you something that has been helpful for me to try to remember when I'm panicking. So, first, you gotta have clear intentions, right? If you're in the mental state of extreme, like frustration, and you don't even have a hypothesis yet. You're just trying a bunch of things.

[00:02:02]
It's just time to take a break, you won't be able to understand your code in that mental state. I usually like to walk through the code line by line to check every single assumption that I making on every line. I'm like, okay, it says it's doing this, I expect it's going to be here at this point.

[00:02:27]
Using console logs. But if you're using more than four to five, it's time to use the debugger again to try to figure out what's going on. Number four is actually my biggest tip. This sounds really, really dumb, but if you're facing problem, and you can't figure out where the hell this is coming from.

[00:02:43]
I just start commenting out code, just I'm like, comment out code. Did the bug disappear? No. Keep commenting out more, and more, and more code until the problem disappears. And I'm like, ha, there it is. And I start reintroducing code slowly to try and figure out the general area of where the problem is.

[00:03:02]
And then I use the assumptions, console logs, debuggers, then in that more specific area to understand what's going on. Number 5 is to use essentially a rubber ducky, whether you're talking to another person, your pet, a toy. Just somehow the act of explaining it out verbally helps you catch maybe assumptions you are making and gives you little insights to figure out what to do next.

[00:03:32]
Ask for help, and if you don't have anyone to help you, none of this is working. Time to take a mental break, walk, naps, eat and try again.
>> Francesca Sadikin: Okay, so that was the wrap up of our super technical portion. I have these recommended resources. So as I mentioned before, Clean Code is just a standard engineering handbook that most engineers find really useful.

[00:04:04]
It goes into Clean Code tactics in detail. Practical object oriented design and agile primer using Ruby by Sandy Metz. So, if you are interested in learning the solid principles. So this is another, like, Clean Code thing where these principles I find actually helps you architect code like architect systems in a clean and extendable way.

[00:04:32]
I really like her book because she explains it very, very well. It is in Ruby, but Ruby is a very readable language, and I actually apply the same learnings in every language that I work in, not just object-oriented languages.