Detangling Your Javascript

Tangled JavaScript code is hard to read, understand and maintain, but it's not broken -- yet. I teach the foundational principles of detangling (or refactoring) JS code to keep your code clean, legible and bug-free.

Transcript

1. Detangling Your JavaScript An Intro to JS Refactoring
2. Chris Powers Engineering Manager at Groupon @chrisjpowers
3. A Conversation
4. “Are you using JavaScript or jQuery?”
6. What is “Tangled” JavaScript?
7. It is not BROKEN code!
8. Broken code doesn’t work.
9. Tangled code does work, but...
10. Tangled code will become “broken” code eventually because...
11. Tangled code is hard to read and understand.
12. Tangled code is hard to update and maintain.
13. Tangled code is easy to accidentally break.
14. “Tangled code is code based on lost requirements.” - Noel Rappin
15. Tangled code was shaped by forces that YOU aren’t aware of
16. Got Tangled Code? Do you...
17. Option #1: Big Bang Rewrite
18. Option #2: Detangle (Refactor)
19. ALWAYS Detangle! NEVER Rewrite!
20. (well, almost)
21. Rewrite good code. Refactor tangled code.
22. Wat? Rewrite good code?
23. Rewrites are good for fixing performance and architecture bottlenecks
24. Rewrites are tempting
25. Coders want to Code!
26. OMG guys, let’s rewrite this in Coffeescript and Ember and D3!!!
28. Writing code is easier than reading code.
29. You CANNOT rewrite code you don’t understand.
30. Your rewrite will likely miss requirements
31. In your client’s eyes, your rewrite will be worse than the original.
32. What is Refactoring?
33. Methodically improving code quality without altering behavior.
34. Making your complex code simple.
35. Simple code is...
36. #1 Tested
37. #2 Reveals Intent
38. #3 DRY - Each piece of knowledge exists in only one place
39. #4 Small
40. 87% of refactoring is improving naming
41. What ISN’T Refactoring?
42. Making changes to untested code is not refactoring.
43. That’s just changing shit.
44. Turning JS into Coffeescript is not refactoring.
45. That’s just... silly.
46. Let’s Start Detangling! Ready... Set...
48. Before refactoring, you may take 30 seconds to rage.
49. It’s cool, I’ll wait.
51. Okay, now STOP IT!
52. You don’t know what forces affected this code, you might have done the same.
53. A certain level of respect for the code is necessary.
54. First Things First: Set a Goal
55. How much code needs to be refactored? How deeply?
56. Write a Test!
58. Why write tests?
59. Makes the code simple
60. Ensures Behavior Does Not Change
61. Forces Developer to Understand Requirements
62. Defines the public API, if originally unclear
63. Refactoring #1 Name the Anonymous Functions
64. BEFORE
65. AFTER
66. Refactoring #2 Document Responsibilities with Comments
67. “Comment Driven Refactoring” (patent pending)
68. BEFORE
69. AFTER
70. Refactoring #3 Extract Methods
71. BEFORE
72. AFTER
73. Refactoring #4 Improve Variable Names
74. BEFORE
75. AFTER
76. Refactoring #5 Add Local Vars to Improve Legibility
77. BEFORE
78. AFTER
79. Keep Extracting Functions
80. BEFORE
81. AFTER
82. Refactoring #6 Add Clarity with Underscore.js
83. BEFORE
84. AFTER
85. Refactoring #7 Isolate Display Logic
86. BEFORE
87. AFTER
88. Refactoring #8 Isolate DOM Manipulation
89. BEFORE
90. AFTER
91. Refactoring #9 Hide “Private” Methods in Closures
92. BEFORE
93. AFTER
94. Refactoring #10 Scope Public Methods in Namespaces
95. BEFORE
96. AFTER
97. Refactoring #11 Use Nested Namespaces
98. BEFORE
99. AFTER
100. Refactoring #12 Extend Namespaces (Don’t Overwrite)
101. BEFORE
102. AFTER
103. Refactoring #13 DRY Up Namespace Initialization
104. BEFORE
105. AFTER
107. AFTER
108. Got questions? @chrisjpowers