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

Taking the pain out of refactoring - MKGN March

Taking the pain out of refactoring - MKGN 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 05, 2015
Tweet

Transcript

  1. @onishiweb Adam Onishi MK Geek Night - March Taking the

    pain out of Refactoring
  2. @onishiweb @onishiweb Hello!

  3. @onishiweb Hello!

  4. @onishiweb Old code sucks! Hello!

  5. @onishiweb - me “…we’re constantly evolving our practices so regularly

    with the environment changing around us every day, you look back on code you wrote a few months ago and wonder what on Earth you were thinking.” http://bit.ly/old-code-sucks Hello!
  6. @onishiweb What is Refactoring?

  7. @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 What is Refactoring
  8. @onishiweb Why is Refactoring important?

  9. Importance @onishiweb

  10. @onishiweb Clarity Maintainability Efficiency DRY http://jina.github.io/refactoring/ Importance

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

    rules. A developer new to the project should be able to understand it.” Importance
  12. @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.” Importance
  13. @onishiweb Efficiency “It should be easy for a developer to

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

    efficient selectors, and not be overly repetitive or nested.” Importance
  15. @onishiweb Spotting bad code

  16. @onishiweb Front End https://flic.kr/p/8RSfDf Bad code @onishiweb

  17. @onishiweb Code Smells Bad code

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

    values Brute forcing Reactive ! important IDs Loose Class names Bad code
  19. @onishiweb Preparation

  20. @onishiweb When is right to refactor? Preparation

  21. @onishiweb Preparation ALL the time, is a good time!

  22. @onishiweb Mental preparation! Preparation

  23. @onishiweb Be pragmatic Improve the product Help other developers Learn

    something new! Preparation
  24. @onishiweb Set Goals Preparation

  25. @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 Preparation
  26. @onishiweb S.M.A.R.T Goals Preparation

  27. @onishiweb Tools

  28. @onishiweb Sassy CSS Tools

  29. @onishiweb Version Control Tools

  30. @onishiweb Build tools Tools

  31. @onishiweb Scss-lint Tools

  32. @onishiweb Tools http://bit.ly/front-end-rules

  33. @onishiweb Tools

  34. @onishiweb Scss-lint Stylestats Tools

  35. @onishiweb Scss-lint Stylestats PerfBudget Tools

  36. @onishiweb refactoring in practice

  37. @onishiweb Our goals In practice

  38. @onishiweb Partials to have <300 lines of code Maximum nesting

    of 4 levels deep Code should adhere to The Rules Ability to use autoprefixer In practice
  39. @onishiweb Naming conventions In practice

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

  41. @onishiweb In practice

  42. @onishiweb In practice

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

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

  45. @onishiweb Breakpoints In practice

  46. @onishiweb In practice

  47. @onishiweb Using Scss-lint In practice

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

    In practice
  49. @onishiweb In practice

  50. @onishiweb In practice

  51. @onishiweb Breaking up existing files In practice

  52. @onishiweb /pages/_sys-archive.scss /pages/_sys-single.scss /components/_sys-select.scss /components/_sys-filter.scss In practice

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

    file "_sys-filter.scss" .sys-filter { [...] } In practice
  54. @onishiweb Experiment In practice

  55. @onishiweb In practice “Why You Should Avoid Sass @extend” http://www.sitepoint.com/avoid-sass-extend/

  56. @onishiweb In practice @include vs @extend

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

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

    248.8KB Gzipped: 29.0KB In practice
  59. @onishiweb refactoring in a team

  60. @onishiweb Git Teams

  61. @onishiweb Teams Fix conflicts on feature branches

  62. @onishiweb Teams Code reviews

  63. @onishiweb Wrapping up

  64. @onishiweb Clarity, Maintainability, Efficiency, DRY Prepare yourself Set S.M.A.R.T goals

    Use tools to help Summary
  65. @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 Summary
  66. @onishiweb Thank you Adam Onishi MK Geek Night - March