Coding Efficiently

Introduction

We’ve covered a lot of material in this course. Along the way, we’ve focused on the essentials of various topics but left out a deeper study in the interest of expediency. In this chapter, we summarize what was learned, both in terms of topics and best practices. We also outline the process we followed for creating a web application… Where to, next? We describe a selection of projects that could help us solidify our new skills and then discuss the long list of what we didn’t cover.

Updating and managing our code

The first deployment of a project usually only makes up a small portion of the project’s lifecycle, especially if the developers smartly built a minimal version to start with. Most of a project’s existence will involve making improvements to the code. As such, updating and managing our code deserves some discussion.

If we follow the Minimal Viable Product approach, we’re likely to have many ideas for improving our application. There should be a list of features filed under “To Do”. The first step in improving the code is to manage this To-Do list, often called the backlog. Agile development practices recommend that the creation and prioritization of the backlog be tied as closely as possible to what will make users happier. This is a codification of the idea that happy users define successful code. This is generally a good practice to follow. In a hobby project, the developer is often the user, so this happens naturally. It’s important to get early versions of the software in front of users to get their feedback in other cases. Turning their feedback into backlog items is a difficult art and worthy of study.

Once we’ve prioritized the backlog, we need to be careful about taking on too much. If we start working on a dozen improvements simultaneously, we have to think about all the ways those improvements could interact with each other. It’s better to take on just one or two items at a time or choose items known in advance not to interfere. Add the idea of breaking the improvements down into workable chunks, and we have Agile Sprints. These are just a few weeks in which we knock out a shortlist of top priority items. The advantage of this approach is that it lets us focus on improving, but periodically, between sprints, forces us to go back and re-prioritize the backlog.

Use Git

As we make changes, it’s a good practice to use git branches to keep things organized. A git branch is a copy of the repository easily created and merged back into the main or master branch. When deploying to Heroku, branches are fundamental because the master branch is the deployed branch. We don’t want to deploy each step as we create an update, but we want those updates committed to the repository. To achieve this, we create a new branch, to add a cool new sidebar.