More Related Content


Similar to Tampere Goes Agile 2013 - Managing a Clean Codebase(20)


Recently uploaded(20)

Tampere Goes Agile 2013 - Managing a Clean Codebase

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

Editor's Notes

  1. Software developer at Vincit * Mainly programming * Mainly embedded software * Medical devices * Mainly C/C++, Python VCS & review training ** Internal & external
  2. Founded in 2007 79 employees
  3. Our client → we have many clients and all of them are happy to work with us
  4. 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
  5. 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?
  6. 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
  7. Reviewing subtopic start note
  8. Clean Code 2 by Steve McConnell, p470 Jeff is inventor of stackoverflow
  9. * Knowledge sharing * Learing from others (new people especially) * Avoid code duplication * All code is known more than one person
  10. 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
  11. 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!
  12. 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
  13. 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
  14. 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
  15. Don't Repeat Yourself – CI subsection start note
  16. 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
  17. 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
  18. Testing
  19. Run (and write) unit tests Trying the feature out You should be ashamed if someone else finds issue in your code
  20. You know how it was made and know how to use it
  21. There should be no delay between implementation and verification If there is the problem is * relearning the change * changed requirements / specification
  22. 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?
  23. 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)
  24. 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
  25. We have discussed * reviewing * CI * testing To How we do it
  26. 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
  27. Do not select tools we use because we use those → evaluate yourself A tool should not dictate how to do things, you should
  28. 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
  29. No separate reviewers No separate check lists defined * Different kind of code/change requires different kind of attention * Use common sense!
  30. After review one commit still contains the one change No found bugs in the history of main branch
  31. Triggers CI Creates review * automatic notifications to email
  32. We have discussed how we do thing at Vincit * do all checks at review time * the used tools To experiences
  33. 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
  34. Comment in gerrit You learn new ways for solving problems
  35. In a 10-15 person project reviewing changes has taken clearly less than 10% of our time
  36. We have checks to prevent bad code entering the code base Everybody knows bad solutions are not accepted
  37. We just had shortly what kind of experiences we have had And the most important thing was...
  38. Nothing else matters (except that you should use VCS)