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.

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