Lana Lodge's lightning talk on refactoring emphasizes the importance of improving code structure by addressing 'bad smells' such as duplicated code and long methods. She shares her challenges with a complex controller and discusses strategies like extracting methods and utilizing state/strategy patterns to enhance code quality. The talk serves as both a reflection on her learning journey and a guide for others looking to refine their coding practices.

1. er's Explo ration of
A Beginn Learned
R efactorin g: Lessons
A lightning talk by Lana Lodge

2. this talk
W hy I wa nted to give
● Got really excited about refactoring after
last month's talk
● Wanted to force myself to learn more
● Wanted to force myself to refactor my work
code
● Wanted to engage in feedback here that
might teach me even more

3. resher from last month
Ref
● Is it DRY?(no duplicated code)
● Does the class have one responsibility?
● Does everything change at the same rate?
● Does it depend on things that change less
often than it does?
● SOLID:Single responsibility, module should be
Open for extension and closed for
modification, Liskov Substitution (all subtypes
of an object should answer to all the same
methods),Interface Segregation(NA), Depend
upon abstractions, not concretions

4. ething Sme lls Bad :S
Som
● My project used to be simple....but with
increasing requirements and having been
taught by the last dev who put ALL
FUNCTIONALITY in the controller..I have 1
controller that handles all functionality for
a complex set of forms with over 1000 lines
of code :S...lots of "bad smells"

5. Should You Refactor?
When
According to Refoactoring: Ruby Edition
● Rule of three
● When adding function
● When you need to fix a bug
● As you do a Code Review
● To learn about an exsisting project

6. B ad smells
● Duplicated code
● Long Methods
● Large class
● Long Parameter List
● Divergent Change/ Shotgun Surgery
● Feature Envy
● Data Clumps
● Case Statements
● Speculative generality

7. S ome strate gies I used
● Use comments to extract methods
● Extract Surrounding method
● Replace Type Code with State/Strategy

8. c t Surroundi ng Method
Extra
● If you have code that is different in the
middle of some similar code:
● extract it using yeild
● method do |varInMethod|
varInMethod.do_this
end
def method
create varInMethod
yeild
do other stuff
end

9. place Type code with
Re
Stat e/Strategy
● Like inheritence but not
● Make an object type for every "kind of"
thing with the differing method in that
object type
● Assign an object of the right type to a more
general object
● This is for when your objects change type
during calculations which use this differing
method