Skip to content

Instantly share code, notes, and snippets.

@SafeAF

SafeAF/refactoring-1_my_thoughts_and_philosophy_on_refactoring.md

Last active October 24, 2015 10:53
Show Gist options
  • Save SafeAF/735c65cb722f062ceda8 to your computer and use it in GitHub Desktop.
Save SafeAF/735c65cb722f062ceda8 to your computer and use it in GitHub Desktop.
Download ZIP
refactoring code thoughts, methods, and philosophy
Raw
refactoring-1_my_thoughts_and_philosophy_on_refactoring.md

Refactoring

  1. You don't understand your code unless you can execute it in your head.. in the shower. Pro-points if you can decompose down to assembly and execute.
  2. You learn as much or more about your code through refactoring as when you wrote it the first time, especially applies to architecture.
  3. Refactoring is very often architecture centric/focused (code&data flow/paths, abstraction, composition, systems, coupling & interfaces) vs implementation ( flow control, conditions/constraints, data, operations etc). This makes architecture higher level and therefore requiring deeper thought and different thought processes.
  4. Anytime you are building systems/writing code for even mildly complex programs it is key to map it out on paper first. It seems trivial to the uniniated but it is a definite classifer regarding pro vs nube engineers.
  5. Don't be afraid of breaking things, after all you wrote tests right? YOU DID WRITE TESTS DIDNT YOU?!?! Ouch, that one stings..

SJK

Raw
some_dudes_refactoring_thoughts.rb
from some dudes blog i dont remember sadly
1. Change your mindset. The goal is not to make the system perfect and easy to understand. The goal is to make the system better and easier to understand.
2. It's okay to stop. Start small - even if it's not the final solution. Pick one function, a few lines or even one line of code, and work on that first. Think about creating a pull request with the changes you've just made. Would your peers be able to reason about your changes?
3. Don't be afraid to replace two messes with one mess (of equal and approximate size). It's an evolving process and each piece of code does not need to be final or pretty, it just needs to make your program better in one way. Take another stab at refactoring duplication or complexity once the first step is done. Too many times have I been sucked down the rat hole of trying to fix all the messy parts at once.
4. Find someone to share the experience with. Pair refactoring is a great way to tackle the larger messes.
5. Refactor all the time. When a new feature request comes along, see if you can refactor first, in a separate commit. Then implement the feature. The goal is to make the feature commit simpler.
6. Demand refactoring. If you don't have the support to refactor then get that support or find a company/client that values it. Refactoring makes code better. Better code makes better products and better jobs.
7. I hope that helps. And keep your spirits up. Refactoring isn't easy to do the first time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment