Your Turn

Your mission now is to spend time in your projects doing some refactoring or researching and adding more code smells examples to this tutorial.

Fork this gist and include a link to your PR

Sal Espinosa PR on Matt Pindell's IdeaBox

Next Steps

1. Find your refactoring buddy & decide how you want to work

   • You can pair with them or choose to work independently if you prefer working solo. Either way, come up with a plan, man.

2. Each person will each need to submit a pull request (2 PRs total)

3. Options for what you work on are:

   • Fixing a 'code smell' in a Gametime or Ideabox project
   • Adding a description of another JavaScript or general 'code smell' to look out for to this tutorial.

You Must Follow the Workflow Below

1. Dig into your IdeaBox and Game Time projects and try to identify issues or places for refactoring - OR - choose a code smell to add to this tutorial.
2. Create a Github Issue for the proposed fix or documentation topic.

• Comment or assign yourself to an issue to 'claim it' when you start work on a fix.
  • Why?: This is how you know that you're not duplicating work that someone else is doing on the project.
• Check out a branch and make the fix.
• You will need to submit Pull Requests for any refactors or documentation you make.
• Use the following template as the body of your Pull Request(s)
• In the PR:
  • Tag @martensonbj, @joshuajhun, @rrgayhart.
  • If: you paired with your Refactoring Buddy
    • Tag a member of another refactor team to review the PR
  • Else:
    • Tag your Refactoring Buddy to review the PR
• Review any PRs you have been tagged on.
  • Comment inline on the code or documentation changes. If you like something someone did, let them know. If you have concerns about the change, let them know (nicely). If you have questions, ask them. If you think the PR is good to merge, let them know with a thumbs up or a ship emoji or just regular old words.
• Respond to any comments on your PRs.

A Note on Refactoring

One of the best things about working as a programmer is working with other programmers. We all make mistakes in our code, from Linus Torvalds to InfoSec Taylor Swift to some guy named Fred who just finished a Code School course and added 'software developer' to his LinkedIn profile. It's impossible to know every trick and best practice, and even if you did, you'd still make silly code mistakes in the heat of the moment.

This is why we pair program and have code reviews.

The examples that we pull out in this tutorial are the kinds that every programmer makes. Sometimes it takes a second set of eyes to see where improvements can be made. You'll see them in your code, classmates' code, your instructors' code, your boss's code... etc.

Never be afraid to make a mistake, that's what you learn from!

The examples that we pull out in this tutorial are the kinds that every programmer makes. Sometimes it takes a second set of eyes to see where improvements can be made. You'll see them in your code, classmates' code, your instructors' code, your boss's code... etc.

Never be afraid to make a mistake, that's what you learn from!