Other Peoples' Code

Humans, being complex and fickle, create complex and fickle things. However, dealing with other people and their code is an unavoidable part of being a programmer. Whether we deal with libraries and frameworks constructed by someone else or inherit entire legacy code bases, the challenges are similar. The first step should always be to seek an understanding of the code and its paradigms. When we have a full understanding of the code, we can begin to interface with it in a clean way, enabling us to create new functionality or make improvements on top of existing work. In this chapter, we'll be exploring this topic in more detail and, through the lens of clean code, considering how we can individually take actions to make other people's code less of a pain to deal with.

In this chapter, we will cover the following topics:

• Inheriting code
• Dealing...

Inheriting code

When we join a new team or take on a new project, we are usually inheriting a large amount of code. Our ability to be productive in these inherited code bases is dependent on our understanding of them. So, before we even seek to make the first change, we need to build in our minds a conceptual model of how things work. It's not necessary for it to be exhaustive and complete, but it must enable us, at a very minimum, to make a change and understand exactly what effect that change may have on all the moving parts of the code base.

Exploring and understanding

Understanding a code base fully is not strictly necessary to make use of it nor to make changes to it, but if we don't have a sufficient understanding...

Dealing with third-party code

The landscape of JavaScript is filled with a myriad of frameworks and libraries that can ease the burden of implementing all types of functionality. In Chapter 12, Real-World Challenges, we had a look at the difficulties involved in including external dependencies in our JavaScript projects. The modern JavaScript ecosystem provides a rich variety of solutions here, and so dealing with third-party code is far less burdensome than it was before. Nonetheless, the nature of having to interface with this code hasn't really changed. We must still hope that our selected third-party library or framework provides an interface that is intuitive and well-documented, and functionality that fulfills our requirements.

When dealing with third-party code, there are two crucial processes that will define the ongoing risks or benefits we receive. The first is...

Summary

In this chapter, we have explored the tricky topic of other people's code. We've considered how we can deal with legacy code that we inherit; how we can build our understanding of it, how we can debug and make changes without difficult, and how we can confirm our changes with a good testing approach. We've also covered the difficulty of dealing with third-party code, including how to select it and how to interface with it in a risk-averse way via the Adapter pattern. There are plenty of other things that we could have spoken about in this chapter, but hopefully the topics and principles we have been able to explore have given you a sufficient understanding of how to navigate other people's code with an eye toward a clean code base.

In the next chapter, we will cover the topic of communication. It may not appear relevant but communication, both within...