Then you could also do things like pair program with engineers who know the domain. A lot of times as soon as it's written, it's already stale. Of course, they don't list all the bad things that happen in the code, but they do give a lot, and so this is not true for generally your company where documentation is either nonexistent or it's very limited or stale. For open source libraries that are supported, there's a lot usually. This involves seeing what documentation exists. In the planning phase, the first thing we want to do is really just gather some context. Then we move on to the planning phase here.
Do I need a surface level just so I can provide value and see risks, or do I need to know every component here, because I'm taking ownership and need to innovate on it? Planning - Context Gathering The next part is around how much time do you want to invest in this? Do you have an hour, a day, a month? This very much affects how much context you can gather, which leads to the next part of, how much context do you need? Time and the need are intertwined here.
#Intellij sequence diagram code
The define stage is really around defining your problem, which could also be, what is your goal? Are you fixing a very specific bug in some code base? Are you adopting or rolling out some new technology or tool? Or are you trying to understand some complex domain to provide value for teammates and guidance? Or, are you also taking ownership of code? There's various goals, just make sure you're clear. Then, if needed, we can explore the code base and break it down. Breaking things down into three categories is how I did mine, starting with defining the problem, and doing some planning before we actually just jump into code. I wanted to codify or structure it a bit, and maybe provide it as a way that could be helpful for you to build yours, or at least reflect on how you do it, and maybe even share some of the things that work for you. Over time of reading a bunch of code bases both for different companies as well as open source libraries, I see some patterns that I generally follow when I do that. It's something where you have to use it or lose it, and the less you do, the more you're going to lose that skill. Basically, analyzing code, reading code, writing code, it's all an acquired skill that we get better at over time, the more we do. One of the beauties around open source is that we can read the code and we can iterate and create enhancements or bug fixes, and not just submit tickets and hope somebody fixes it for us. Then, lastly, there's a bunch of open source libraries that we've started to use these days, and so being able to understand what you're pulling into your code. Being able to quickly jump in and understand it is vital for some of these time sensitive things. Outside of that, sometimes you have to jump into a domain and own it or bring it forward, or deprecate it, or derisk it.
As you become more senior, the more you are reading code, especially in domains that you know little about, and so being able to jump into a code base to provide guidance and support and not purely friction for engineers, is a big win. Providing Valueĭigging a little bit deeper on the providing value aspect. It can also give you a better understanding of the risk in certain libraries, or tools, or even into your internal code base, what risks exist in domains that you're analyzing. This could also lead to you making better decisions on what types of tools, libraries you adopt. Why is it important? The quicker you can jump into a code base, and understand it, the quicker you can provide value. I want to spend a little time talking about analyzing code bases and why it's important for being a better developer.
#Intellij sequence diagram software
I'm a software engineer at Castlight Health.
0 kommentar(er)
