Software developer at Vincit * Mainly programming * Mainly embedded software * Medical devices * Mainly C/C++, Python VCS & review training ** Internal & external
Founded in 2007 79 employees
Our client → we have many clients and all of them are happy to work with us
More common than what you might think * Just the other day I was working with customer that did not use VCS If you are using RCS, CVS, Clean Case or SourceSafe, you only think you are using VCS RCS, CVS, CC → no atomic commits SourceSafe → reported problems in keeping code uncorrupted
Implementing a feature (or a bugfix) Implement * One complete feature * Clean code that is edited Measure * Test the implementation * Verify that implementation meets requirements Learn * Was the feature usefull * Need to change / adjust / fix?
No exceptions Seen as good thing but many times ignored Code reviewing * Code meets quality standards * Follows agreed conventions Continuous integration * Automate repeating tasks Testing * Verification Let's look all these in more detail
Reviewing subtopic start note
Clean Code 2 by Steve McConnell, p470 http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html Jeff is inventor of stackoverflow
* Knowledge sharing * Learing from others (new people especially) * Avoid code duplication * All code is known more than one person
If implementation needs comments, it is not good enough The original author should not explain the code * this is the case when doing changes * explaining can lead reviewer to wrong path Optimizations should not override readability * Technical debt * Maintenance costs
Reasonable change * Transforms software from working state to working state * All required changes: nothing more, nothing less * Includes tests and documentation etc. * Changes one thing (loc does not matter) * Styling fixes is a separate change → makes reviewing easier Larger reviews still relevant for critical parts of system No cleanup and bugfix in same change!
Style Functionality Architecture Structure Maintainability Readability / clearness Follows agreed conventions / guide lines Tests Change contents (is it a reasonable change) * Hard to review → probably not reasonable Change message * Like good comment; does not repeat but tells why * For bug fixes some description of the bug
Why a change was made What it changes (feature, bugfix) Good change history is your change log Example: commit breaking a feature has commit message repeating the change * original author does not remember why * just have to guess possibly breaking the fixed thing
To outsiders (not coding in the project) * see things differently * make sure code quality meets expectations The other way around also: look at subcontractors code early
Don't Repeat Yourself – CI subsection start note
No time wasted doing the same thing Release builds and publishing release Test image builds Running automated tests / other QA tools Migration tests Example: Creating a tag triggers CI to create release build, installers, source packages + normal testing stuff
This should be the default Can be seen as automated code review step Long build times → optimize build system * buy better hardware * rewrite / rethink build system
Run (and write) unit tests Trying the feature out You should be ashamed if someone else finds issue in your code
You know how it was made and know how to use it
There should be no delay between implementation and verification If there is the problem is * relearning the change * changed requirements / specification
So how for long does the iteration lasts? Code reviews usually after change has been “done” CI done usually after change has been “done” Testing (by testers) is done after change has been “done” → The task iteration cycle is longer than you think! How iteration time can be reduced?
Before including a change in main development branch * Review * run CI (tests) * test the change → aim for having always ready for deployment main branch (continuous deployment would be possible)
Publish: put into main development branch Approval * Review, Automated tests, testing passed Definition of done Hurry should not be a reason to cut corners * make approving fast enough to not have reason to skip approval
We have discussed * reviewing * CI * testing To How we do it
Git * Efficient and versatile * In a way de-facto standard * Steep learning curve Gerrit * Web based review tool * Commit based * Customer access * UI not very intuitive Buildbot (C/C++) / Jenkins (Java) * Has gerrit integration
Do not select tools we use because we use those → evaluate yourself A tool should not dictate how to do things, you should
Implementation * coding * writing tests Review phase * Peer review (possibly customer review) * CI (automated tests and checks) * Testing / verification Done * into main branch and possible deployment One person project can also do this * create review, get CI feedback, take a look later
No separate reviewers No separate check lists defined * Different kind of code/change requires different kind of attention * Use common sense!
After review one commit still contains the one change No found bugs in the history of main branch
Triggers CI Creates review * automatic notifications to email
We have discussed how we do thing at Vincit * do all checks at review time * the used tools To experiences
Comment from colleague after reviewing code for couple of weeks You know that someone WILL look at the code you are producing and will say if he does not like it In one project bashing (lyttääminen) became synonym for reviewing Tolerance for unclear solutions has lowered
Comment in gerrit You learn new ways for solving problems
In a 10-15 person project reviewing changes has taken clearly less than 10% of our time
We have checks to prevent bad code entering the code base Everybody knows bad solutions are not accepted
We just had shortly what kind of experiences we have had And the most important thing was...
Nothing else matters (except that you should use VCS)
Tampere Goes Agile 2013 - Managing a Clean Codebase
Maintaining a Clean Codebase
Passionate Software Developer
Invest your time in reviews
45%-70% of defects are found in code reviews but
only 15%-50% using unit tests.
From Clean Code
“I believe that peer code reviews are the single biggest
thing you can do to improve your code”