One of the issues regarding readability control is that readability is a subjective concept and thus difficult to rely on a general guideline plus devs' self governing to control. Some code review process has been designed to mitigate such risks and in my other post "Another way of coding explained" I also tried to establish some more objective standards for readability. The most effective way of controlling readability, however, is probably pair programming with regular pair switch while both devs in the pair always focus on readability.
Pairing means constant code review, but for readability control purpose, this is not enough. By definition, readability cannot be reviewed by the dev that wrote the code, because obviously if you wrote the code, you don't really need to read it. You already know all the rational behind the code and everything just makes sense to you. This why regular pair switching is also critical for readability control in pair programming.
By regular pair switch, I mean pair switch every 1-2 days so that most medium and plus size stories got implemented by more than 2 devs. Each switch means a little ramp up for the new dev that gets switched into the pair. The dev that remains on the pair needs to explain the story and all the existing code and design decisions with the new dev. This is a great opportunity to put the readability of the code under test. The new dev raises all readability issues he noticed when reading the code. The old dev does (or should do) the same thing when s/he finds some code more difficult to explain than others.
So this is another reason for regular pair switching and pair programming in general.
Good observation. I was talking about this with my pair the other day.
ReplyDeleteMy recommendation (and something I usually do) is this:
If you're the anchor on the story and new person switches in, start by opening the story card in Mingle (or wherever) and share context around acceptance criteria. Then open the classes and tests written so far for the story. And stop. Let the pair read through the code, and understand it without your inputs. Whenever she asks a question, ask a question back to clarify what is unclear. Then in response, refactor the code right there and check again if the changed code explains the intent better. Rinse and repeat.
Similarly when you're the new person switching in, read through code yourself without asking too many code-related questions. If you do feel like asking questions, get those answered, and then collectively refactor with your pair till you both are satisfied wrt expressing intent. Rinse and repeat.
The above may seem idealist and as if it'd take longer than simply asking and answering questions, but in practice I haven't seen it take long (sometimes it even shortens unnecessary conversation!), and the benefits are well worth it.
Hey Aman,
ReplyDeleteThat's a very good practice. The principle is that the new person in the pair should be able to easily read the code by herself, if not, refactoring is needed.