Save 37% off PRO during our Black Friday Sale! »

Taking the pain out of refactoring - SecWed March

Taking the pain out of refactoring - SecWed March

Refactoring can be tough. To look in detail at old code you've written to identify the weaknesses can be a really soul destroying experience. Whether it's finding code you've written that retrospectively could have been better, or forcing yourself to look at code you thought was brilliant but instead see the flaws and improvements that could be made.

But refactoring doesn't have to be a painful experience, it can be a joy. To watch your code improve, become more succinct, more thought out, and more performant is fantastic. In this talk, I'll cover some of the great sides to refactoring a front-end project, looking at recent work from a large project refactor I've been working on. I'll look at how you can set some good rules and goals for your refactoring. Take a look at tools to make the job easier. As well as things like how to prepare your state of mind for what can be a very tough process.

Fc7368fd45560e1e7401bc80684f5867?s=128

Adam Onishi

March 11, 2015
Tweet

Transcript

  1. @onishiweb Taking the pain out of Refactoring Adam Onishi Second

    Wednesday - March
  2. @onishiweb Front End Cheese @onishiweb https://flic.kr/p/8RSfDf

  3. @onishiweb “Code Smells” Cheese

  4. @onishiweb My code, stinks!

  5. @onishiweb Cheese

  6. @onishiweb Old code sucks! http://bit.ly/old-code-sucks Cheese

  7. @onishiweb Refactoring!

  8. @onishiweb - Martin Fowler “The process of changing a software

    system in such a way that it does not alter the external behaviour of the code yet improves its internal structure.” http://bit.ly/refactoring-book Refactoring
  9. @onishiweb Why refactor? Refactoring

  10. @onishiweb Refactoring

  11. @onishiweb Clarity Maintainability Efficiency DRY http://jina.github.io/refactoring/ Refactoring

  12. @onishiweb Clarity “Code should be clear, well- commented, and follow

    consistent rules. A developer new to the project should be able to understand it.” Refactoring
  13. @onishiweb Maintainability “Code should be easy to update & maintain,

    not requiring hacks or over-specific styles. It should be clear where files and styles belong.” Refactoring
  14. @onishiweb Efficiency “It should be easy for a developer to

    find where styles live, write new styles, fix bugs, or find documentation and instructions.” Refactoring
  15. @onishiweb DRY “Don't repeat yourself! Code should be reusable, have

    efficient selectors, and not be overly repetitive or nested.” Refactoring
  16. @onishiweb CSS & Sass Smells

  17. @onishiweb http://bit.ly/css-smells Undoing styles Magic Numbers Qualified/Dangerous selectors Hard-coded values

    Brute forcing Reactive !important IDs Loose Class names Too much nesting Code smells
  18. @onishiweb My Smelly code… Code smells

  19. @onishiweb When do you refactor?

  20. @onishiweb All the time! When

  21. @onishiweb - Robert “Uncle Bob” Martin “The act of leaving

    a mess in the code should be as socially unacceptable as littering.” http://deviq.com/boy-scout-rule/ When
  22. @onishiweb Set Goals When

  23. @onishiweb - Amaury Moulron “We have currently 9,000+ selectors —

    that’s pre-refactoring. Once done, we’re aiming at 5,000 selectors.” http://bit.ly/buzzfeed-sass When
  24. @onishiweb @onishiweb When

  25. @onishiweb S.M.A.R.T Goals for refactoring When

  26. @onishiweb Our goals When

  27. @onishiweb - Partials to have <300 lines of code -

    Maximum 4 levels of nesting - Code should adhere to our “Rules” - Ability to use autoprefixer When
  28. @onishiweb Names of stuff

  29. @onishiweb - Phil Karlton “There are only two hard things

    in Computer Science: cache invalidation and naming things.” Naming
  30. @onishiweb Sassy CSS Naming

  31. @onishiweb $clr-lightblue:#4BCEFA; $clr-pink:#F96EC4; $clr-orange:#FFB400; $clr-green:#8DD400; $clr-purple:#009edc; Naming

  32. @onishiweb Naming

  33. @onishiweb Naming

  34. @onishiweb $clr-lightblue:#F02233; // RED! $clr-pink:#F96EC4; $clr-orange:#FFB400; $clr-green:#8DD400; $clr-purple:#009edc; Naming

  35. @onishiweb $clr-brand:#4BCEFA; $clr-activities:#F96EC4; $clr-parenting:#FFB400; $clr-sustainability:#8DD400; $clr-mmr:#009edc; Naming

  36. @onishiweb Breakpoints Naming

  37. @onishiweb Naming

  38. @onishiweb Duplicate styles

  39. @onishiweb Scss-lint scss-lint

  40. @onishiweb .related-products { […] } […] .related-products { […] }

    scss-lint
  41. @onishiweb scss-lint

  42. @onishiweb Scss-lint scss-lint

  43. @onishiweb scss-lint

  44. @onishiweb http://wearearchitect.github.io/Front-end-Rules/ scss-lint

  45. @onishiweb https://github.com/onishiweb/code-style scss-lint

  46. @onishiweb Oversized partials

  47. @onishiweb /pages/_sys-archive.scss /pages/_sys-single.scss /components/_sys-select.scss /components/_sys-filter.scss Size matters

  48. @onishiweb <!-- component --> <div class="sys-filter"> [...] </div> // Sass

    file "_sys-filter.scss" .sys-filter { [...] } Size matters
  49. @onishiweb Experiments!

  50. @onishiweb Why You Should Avoid Sass @extend Experiments http://www.sitepoint.com/avoid-sass-extend/

  51. @onishiweb - Hugo Giraudel “the more a string is repeated,

    the better it is for compression. [… therefore] the difference is likely to be inexistent.” http://www.sitepoint.com/avoid-sass-extend/ Experiments
  52. @onishiweb With @extends Size: 247.9KB Gzipped: 28.9KB With @includes Size:

    248.8KB Gzipped: 29.0KB Experiments
  53. @onishiweb Refactoring in a team

  54. @onishiweb Git Teams

  55. @onishiweb Git Flow http://bit.ly/gitflow Teams

  56. @onishiweb Fix conflicts on feature branch Teams

  57. @onishiweb Code reviews Teams

  58. @onishiweb Refatoring doesn’t have to be painful

  59. @onishiweb Mentally challenging Painless

  60. @onishiweb - Be pragmatic - Be prepared - You’re improving

    the product - Help other developers Painless
  61. @onishiweb There is more to writing code than writing good

    code Be Great
  62. @onishiweb - James Higgs “A good developer can code. A

    really good developer can write clean code. A great developer knows when clean code is a waste of time.” http://youtu.be/znBtzBAS9Bo Be Great
  63. @onishiweb Thank you Adam Onishi Second Wednesday - March