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.

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