Competencies, Behaviours and Knowledge units

• S1: create logical and maintainable code
• S8: create simple software designs to effectively communicate understanding of the program
• S11: apply an appropriate software development approach according to the relevant paradigm (for example object oriented, event driven or procedural)
• S12: follow software designs and functional or technical specifications
• S14: follow company, team or client approaches to continuous integration, version and source control
• S15: communicate software solutions and ideas to technical and non-technical stakeholders
• B7: Communicates effectively in a variety of situations to both a technical and non-technical audience
• B4: Works collaboratively with a wide range of people in different roles, internally and externally, with a positive attitude to inclusion & diversity

Resources

• Slides
• Laptops
• Internet access
• Post-its
• Pens
• Whiteboard
• Paper
• QWAN cards (Mark and Alec have sets of these)

Mentors / Languages

Two–three mentors required in addition to leads. These should be able to cover support for the required languages.

Prep-work for apprentices

• Make sure you can sign in to github.com with your own account
• Fork this repo (so you can push your changes later)
• Clone your fork: git clone https://github.com/[your-username]/apprentice-boot-camp-improving-code.git
  • ⚠️ Don’t use the IDE to clone the project, as it will open the root of the project which is wrong
• Follow the instructions in the README for your language under the exercises directory, making sure that the tests run and pass
  • Java
  • JavaScript
  • C#
• It’s normal to have problems with this, so just let us know! :)

Follow-on tasks

Organisation mentors should look to exercise the knowledge we’ve covered in the boot camp. Below are suggestions for tasks that would do this, but please use your own judgement to work out what to do. There is no need for anything to be returned to MD or the presenters—it’s just a learning exercise.

• Search for code smells in code-bases back at work
• Apply code smell searching and refactoring to portfolio work and document
• Maybe use QWAN cards as a teaching resource to help organise refactoring work
• Apprentices should deliver a code review, and receive feedback about it
• Configure / review static analysis for an existing reasonably sized project (use Codacy if no existing system in use and the code is publicly available)
• Java apprentices can also add Error Prone to an appropriate project—maybe one in it’s early days so that it is possible to introduce
• You could code review their changes in the Code Smell trivia exercise—they can provide you with the address for their fork
• You can see how they reviewed each other’s changes in the exercise—one again they can provide you with a link to their comments

Further reading / learning resources

Books:

• Working Effectively with Legacy Code, First Edition by Michael Feathers
• Refactoring: Improving the Design of Existing Code by Martin Fowler
• Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition by Frederick P. Brooks Jr.

Video:

• The Art of Giving and Receiving Code Reviews (Gracefully) (30 minutes)

Web:

• QWAN Code Smells and Refactoring Cue Cards
• Refactoring Guru’s section on Code Smells—this is an excellent site, and super accessible
• 8 Tips for Great Code Reviews—five minute read with some good top level tips, well communicated. Maybe share this at work if review doesn’t go so well?
• Awesome code review: An "Awesome" list of code review resources - articles, papers, tools, etc
• [Reviewing proposed changes in a pull request]](https://help.github.com/en/articles/reviewing-proposed-changes-in-a-pull-request)

Slides

The slides can be viewed from the link at the top of the repository.

Exercises

• Reading Trivia code base to understand what it does and how it works
• Identifying and removing code smells in Trivia code using refactoring techniques
• Setting up static analysis for codebase to identify and measure violations of automated rulesets
• Identifying and removing more code smells in Trivia code
• Providing code review on each others refactoring work in the Trivia codebase, with emphasis on how to use GitHub to communicate issues and praise effectively

Briefing for organisation mentors

• Familiarise yourself with following code smells using this site
  • Uncommunicative Name
  • Duplicate Code
  • Magic Number
  • Long method
  • Conditional complexity
  • Large class
• Familiarise yourself with the Trivia code base
  • Maybe try refactoring it?
• Understand what the golden master test does, and how to regenerate the golden masters
  • May need to do this if bugs are identified and fixed
• Try setting up www.codacy.com on one of your repos, or a fork of this one

Contributing

If you’d like to contribute changes to the slides or exercises, please see our contributing guidance.