Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Tampere Goes Agile 2013 - Managing a Clean Codebase

  1. 1. Maintaining a Clean Codebase Janne Rönkkö Passionate Software Developer
  2. 2. About Me
  3. 3. 2007 79
  4. 4. Agenda ● Tools to improve code ● How we do it ● Experiences
  5. 5. Use version control
  6. 6. Implement Learn Measure
  7. 7. No bad code allowed! ● Code reviewing ● Continuous integration ● Testing
  8. 8. Do review your code
  9. 9. 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” Jeff Atwood
  10. 10. Benefits from code reviews
  11. 11. Readability may not be sacrificed
  12. 12. Review reasonable change at a time
  13. 13. Nothing shall be left unreviewed ● Looks ● Functionality ● Tests ● Change
  14. 14. Good change history matters
  15. 15. Show your code to others
  16. 16. Don't Repeat Yourself
  17. 17. Automate every repeating tasks
  18. 18. Run all automated tests for every change
  19. 19. Verify your implementation
  20. 20. Test your change yourself
  21. 21. Let someone else try your change
  22. 22. Test immediately
  23. 23. How long one iteration takes? Implement Learn Measure
  24. 24. Prevent instead of reacting
  25. 25. Do not publish unapproved changes
  26. 26. Agenda ● Tools to improve code ● How we do it ● Experiences
  27. 27. Tools we use ● Git ● Gerrit ● Buildbot / Jenkins
  28. 28. Use tools that fit
  29. 29. Coding Review CI Test Done
  30. 30. Review with common sense
  31. 31. All the commits are reviewed, bad ones are fixed
  32. 32. Agenda ● Tools to improve code ● How we do it ● Experiences
  33. 33. “We have become more disciplined”
  34. 34. “That is a nice way of doing that”
  35. 35. Reviewing is fast
  36. 36. Reviewing has improved our code
  37. 37. Agenda ● Tools to improve code ● How we do it ● Experiences
  38. 38. Bad Code Not Allowed
  39. 39. Janne.ronkko@vincit.fi http://www.vincit.fi/

Editor's Notes

  • 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
  • Testing
  • 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)
  • ×