Tampere Goes Agile 2013 - Managing a Clean Codebase
•Télécharger en tant que ODP, PDF•
0 j'aime•1,287 vues
By Janne Rönkkö
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (16)
Similaire à Tampere Goes Agile 2013 - Managing a Clean Codebase
Similaire à Tampere Goes Agile 2013 - Managing a Clean Codebase (20)
Plus de VincitOy
Plus de VincitOy (12)
Dernier
Dernier (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
- 5. Agenda ● Tools to improve code ● How we do it ● Experiences
- 8. No bad code allowed! ● Code reviewing ● Continuous integration ● Testing
- 9. Do review your code
- 10. 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
- 11. Benefits from code reviews
- 12. Readability may not be sacrificed
- 13. Review reasonable change at a time
- 14. Nothing shall be left unreviewed ● Looks ● Functionality ● Tests ● Change
- 15. Good change history matters
- 16. Show your code to others
- 18. Automate every repeating tasks
- 19. Run all automated tests for every change
- 21. Test your change yourself
- 22. Let someone else try your change
- 23. Test immediately
- 24. How long one iteration takes? Implement Learn Measure
- 25. Prevent instead of reacting
- 26. Do not publish unapproved changes
- 27. Agenda ● Tools to improve code ● How we do it ● Experiences
- 28. Tools we use ● Git ● Gerrit ● Buildbot / Jenkins
- 29. Use tools that fit
- 31. Review with common sense
- 32. All the commits are reviewed, bad ones are fixed
- 34. Agenda ● Tools to improve code ● How we do it ● Experiences
- 35. “We have become more disciplined”
- 36. “That is a nice way of doing that”
- 38. Reviewing has improved our code
- 39. Agenda ● Tools to improve code ● How we do it ● Experiences
- 40. Bad Code Not Allowed
Notes de l'éditeur
- 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)