I've been working on kind of cheat sheet for the development team, and I thought I'd post it here too as it counts as geek :)
-->
-->
Pair programming
Pair programming is a
technique that hopes to achieve three main things. Those being: better
architectural design, shared knowledge and code quality. Pair programming often
reduces waste during code review as core concepts are already decided, leading
to fewer rewrites. When done well it helps to build trust and
understanding between developers. The following steps are all equally important
and can be considered a cheat sheet.
·
Define the task, with small goals in mind. You’ll then be able to move in the same
direction quickly.
·
Agree on the solution. It’s worth spending a little time before
coding to fix in your minds how your solution will work.
·
Talk constantly about what you are both
doing.
·
The developer with the keyboard writes, while
the other one directs. An
analogy is that of driver and a navigator. The driver at the keyboard makes the
tactical decisions while the navigator keeps them on course and suggests short
cuts.
·
Switch roles at least every two hours.
·
Consider checking into a temporary
pair-programming local branch in git at each swap point. This shouldn’t be master.
Code Reviews
Code reviews are there to
catch mistakes, keep the code base balanced and gain the insight of another
pair of eyes before you submit your work to the wider business. It’s there to
help and protect you, not to criticize you or force you to change complete direction.
When you are reviewing others code, you should be wary of asking for changes to
make the code look like you had written it. The following points should be
considered during code review.
·
Select a reviewer as close to the code as
possible. Therefore if you are
pair programming or working with someone on a user story, they should be the
reviewer. You must stick with this reviewer for re-reviews.
·
If at all possible, do code review together at
a desk before it is even pushed to Gerrit. Even better correct problems there and then. This
makes it more immediate, less confrontational, more productive and a better
experience all round.
·
Review the code, not the coder. Refer to the code, not the coder. Don’t say ‘your code here tests the wrong
object’ but ‘this code tests wrongObject, not rightObject’
·
The reviewer should assume that things have
been done by the reviewee for good reason. The developer has likely given it more thought than
the reviewer, so challenges to how something has been done should be diplomatic
and open. Equally, the developer may not have thought of everything and may not
have thought of the best solution. When such things are raised in review, they
should be discussed and either corrected or clarified (e.g. better code
structure or comments may resolve the issue).
·
The developer should not take feedback as
personal criticism. They
should view them as honest questions/feedback aimed at ensuring that the
delivered code is of an acceptable quality (fulfills the requirement, complies
with best practice in terms of architecture, design and code etc.). Any
feedback should be considered openly and as an opportunity for improvement,
learning and to deliver a better end product.
·
Be clear in identifying the issue and suggest
obvious fixes. ‘This doesn’t
work’ is worse than useless.
·
Programming style should be challenged not
demanded. Rather than saying ‘This
code style is not following a pattern’ say ‘Consider the use of the Command
Pattern?’ This however is not an excuse to ignore best practice or consistency
issues with the code by the developer.
·
When you review code you become part of that
story. If a reviewer just
rubber stamp the review, they’re directly responsible for failure. If they sit on
a review, or re-review you are responsible for it being held up. Check you
requested reviews often.
·
Always respond to every code review comment in
Gerrit. Either with “Done” or
with a suitable response. This aids re-review.
·
Point out the good. When reviewing code you may learn things
yourself or spot elegant solutions. When that happens, say so, the coder may be
unsure that it was elegant and it positively reinforces the good stuff.
Checking in
Git is complex and
powerful, and there is a lot to say on it, however these general check-in
points are important.
·
The code you write is valuable and needs to be
backed up as much as possible so that there is no danger of losing it.
·
Check the code in at end of the day. Otherwise you are preventing others from
picking up the work to get it finished. We can’t ever predict what will happen
from one day to the next in terms of illness or transport problems.
·
More frequent commits mean more flexibility in
code reviews. This leads to
faster turnaround and less context switching. Small commits are easier to understand, easier
to review, and can be merged to master much sooner. This means that your code
gets picked up by others sooner, reducing the complexity of conflict
resolution, and ensuring that your code is in use sooner which gives you a higher
degree of confidence that there are no corner cases that you missed in your
unit testing.