Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Thames Valley Meetup: Refactoring
Search
Jack Franklin
November 05, 2014
Technology
1
190
Thames Valley Meetup: Refactoring
Jack Franklin
November 05, 2014
Tweet
Share
More Decks by Jack Franklin
See All by Jack Franklin
Advanced React Meetup: Testing JavaScript
jackfranklin
1
220
Components on the Web: Frontend NE
jackfranklin
1
800
ReactiveConf: Lessons Migrating Complex Software
jackfranklin
0
460
Front Trends: Migrating complex software
jackfranklin
1
800
Migrating from Angular to React: Manc React
jackfranklin
1
170
Half Stack Fest: Webpack
jackfranklin
4
530
FullStackFest: Elm for JS Developers
jackfranklin
1
220
Codelicious: Intro to ES2015
jackfranklin
0
360
PolyConf: Elm for JS Developers
jackfranklin
0
270
Other Decks in Technology
See All in Technology
AI専用のリンターを作る #yumemi_patch
bengo4com
4
2k
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
200
ハッカソン by 生成AIハッカソンvol.05
1ftseabass
PRO
0
140
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
160
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
1
160
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
150
WordPressから ヘッドレスCMSへ! Storyblokへの移行プロセス
nyata
0
340
より良いプロダクトの開発を目指して - 情報を中心としたプロダクト開発 #phpcon #phpcon2025
bengo4com
1
3.2k
AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions
matsuihidetoshi
1
310
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
4
1.5k
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
1
310
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
140
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.1k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Balancing Empowerment & Direction
lara
1
390
Become a Pro
speakerdeck
PRO
28
5.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Facilitating Awesome Meetings
lara
54
6.4k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Transcript
Refactoring Reafctoirng
@Jack_Franklin
None
changing the design not the behaviour
None
None
None
beware, opinions!
"Any fool can write code for a computer to understand.
Good programmers write code that humans can understand" ! Martin Fowler
None
// create the carousel ! carousel( 400, 500, $('img'), 1000,
2000, true );
function carousel( height, width, images, speed, delay, autoPlay ) {
// code }
// create the carousel ! carousel({ height: 400, width: 500,
… });
var h = 400; var w = 400; var play
= true; var calc = function()… ! for (var key in things)
Name things after their intention
"There are only two hard things in Comp Sci, cache
invalidation and naming things" ! Phil Karlton
var placePin = function(x, y) ! var getLatLon = function(x,
y) ! var user = { coordinates: [x, y] }
var placePin = function(coords) ! var getLatLon = function(coords) !
var user = { coordinates: { x: 1, y: 2 } }
implicit knowledge
if I were to hand the code over to you,
what do I have to explain?
var drawGraph = function(width, height) { width = 160 +
width; height = 172.5 + height; }
None
! var drawGraph = function(width, height) { var graphWidthPad =
160; width = graphWidthPad + width; … }
implicit knowledge is what trips future you up in 6
months time
function someFunc() { doSomething() and.then.something.else(); maybe.even.more(); var x = 2;
var y = 3; keep.on.going(x); and.going.and.going(y); return on.and.on(); }
strive for reusable, composable functions
this makes sure they do one thing and one thing
well
and also makes them much easier to test
easy to test code is usually pretty good
var goToBeginning = function(carousel) { if(carousel.isAtEnd()) { carousel.goToStart(); } }
var goToBeginning = function(carousel) { if(carousel.isAtEnd()) { carousel.goToStart(); } }
carousel goToBeginning
carousel.goToBeginning = function() { if(this.isAtEnd()) { this.goToStart(); } }
Component Component Component Component Component Component Component Component Component Component
components should know little about each other
one thing well
doing this in real life
120 seconds
you will never get this right
you never know less about the problem
premature abstraction is the root of all evil
prefer duplication at first
/users ?created_at[gt]=2014-04-01 &created_at[lte]=2014-05-01 ! if params[:created_at][:gt] users = users.where("created_at >…")
if params[:created_at][:lte] …
if params[:created_at][:gt] users = users.where("created_at >…") ! if params[:created_at][:lte] …
! if params[:created_at][:gte] … ! if params[:created_at][:lt] …
None
filters = params[:created_at] ! map = { lte: '<=', gt:
'>', … } ! filters.reduce(User.all) do |col, (key, val)| sym = map[key] col.where("created_at #{sym} ?", …) end
None
you can be too clever for your own good
filters = params[:created_at] users = User.all ! filters.reduce(users) do |coll,
(key, val)| case key when :lte then coll.where(…) when :gt then coll.where(…) … end
None
prefer clarity of intent over succinct code
if something goes wrong, back out
git commit all the time
you should rebase before pushing anyway
it's a slow, methodical, mechanical process
test driving features
Can a user subscribe? • NO if they are the
owner of the blog • NO if they are an admin of the blog • NO if they are already subscribed to the blog • NO if the blog is private • Else, totally.
given input X I expect output Y
pure function! input X > same output Y no side
effects
you should strive for pure functions
they are easy to test and less prone to causing
large errors
Can a user subscribe? • NO if they are the
owner of the blog • NO if they are an admin of the blog • NO if they are already subscribed to the blog • NO if the blog is private • Else, totally.
it "returns true if the user can" do res =
UserSubscribe.can_subscribe? (user_id, blog) expect(res).to be(true) end
class UserSubscribe def self.can_subscribe? (user_id, blog) true end end
None
it "returns true if the user can" … ! it
"returns false if the blog is private" …
None
class UserSubscribe def self.can_subscribe? (user_id, blog) !blog.private? end end
None
it "returns true if the user can" … ! it
"returns false if the blog is private" … ! it "returns false if the user owns the blog" …
None
class UserSubscribe def self.can_subscribe?(user_id, blog) if blog.private? false elsif user.owns?(blog)
false else true end end end
None
it "returns true if the user can" … ! it
"returns false if the blog is private" … ! it "returns false if the user owns the blog" … ! it "returns false if the user is admin" …
class UserSubscribe def self.can_subscribe?(user_id, blog) if blog.private? false elsif user.owns?(blog)
false elsif user.is_admin?(blog) false else true end end end
it "returns true if the user can" … ! it
"returns false if the blog is private" … ! it "returns false if the user owns the blog" … ! it "returns false if the user is admin" … ! it "returns false if the user is subscribed" …
class UserSubscribe def self.can_subscribe?(user_id, blog) if blog.private? false elsif user.owns?(blog)
false elsif user.is_admin?(blog) false elsif user.is_subscribed?(blog) false else true end end end
None
the first implementation doesn't matter
the first implementation is about understanding the problem
None
class UserSubscribe def self.can_subscribe?(user_id, blog) if blog.private? || user.owns?(blog) ||
user.is_admin?(blog) || user.is_subscribed?(blog) false else true end end end
class UserSubscribe def self.can_subscribe?(user_id, blog) ! !(blog.private? || user.owns?(blog) ||
user.is_admin?(blog) || user.is_subscribed?(blog)) ! end end
class UserSubscribe def self.can_subscribe?(user_id, blog) ! return false if blog.private?
return false if user.owns?(blog) return false if … return false if … true end end
None
prefer clarity of intent over succinct code
TDD doesn't work every time
(but that doesn't mean you shouldn't write tests!)
but sometimes it might make sense to write the tests
afterwards...
#TODOs don't get done
None
49,732,824
Code Review
Code Review
None
Making a difficult change
refactor to make the change easy
make the change
RubyRogues #178 ! http://devchat.tv/ruby- rogues/episode-guide
Refactoring Book ! http://refactoring.com/
Thoughtbot Blog ! http:// robots.thoughtbot.com/
Thank You! ! @Jack_Franklin ! http://javascriptplayground.com/ the-refactoring-tales/