Tidy First?

Part II. Managing

Tidying is software design addressing you, your relationship to your code, and ultimately your relationship with yourself. In the next book in the series, we’ll talk about how and why teams perform software design together. After that we’ll talk about software design and its role in relationships with nonprogrammers. Tidying is geek self-care.

The mechanics of the tidyings will come to you with practice. Most of them require no automated support. Programming environments inexplicably lack automated support for refactoring even now, decades after it became feasible. But okay. I want you to get used to designing software a little at a time, all the time. Tidyings are gateway refactorings.

Just being able to identify that a tidying applies and applying it doesn’t mean you’ve mastered tidying. The title of this book is Tidy First?, with emphasis on the question mark. I wanted to acknowledge that just because you can tidy doesn’t mean you should tidy.

This section on managing tidying discusses how to fit tidying into a personal development workflow:

• When do you start tidying?

• When do you stop tidying?

• How do you combine tidying, changing the structure of the code, with changing the behavior of the system?

We’ll start by discussing how tidying interacts with pull requests and code reviews.