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
180
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
170
Components on the Web: Frontend NE
jackfranklin
1
680
ReactiveConf: Lessons Migrating Complex Software
jackfranklin
0
390
Front Trends: Migrating complex software
jackfranklin
1
690
Migrating from Angular to React: Manc React
jackfranklin
1
130
Half Stack Fest: Webpack
jackfranklin
4
460
FullStackFest: Elm for JS Developers
jackfranklin
1
200
Codelicious: Intro to ES2015
jackfranklin
0
320
PolyConf: Elm for JS Developers
jackfranklin
0
250
Other Decks in Technology
See All in Technology
Tableau事例紹介 / Tableau Case Study of Eureka
kazuya_araki_tokyo
1
180
Databricks における 『MLOps』
databricksjapan
2
160
Janus
bkuhlmann
1
490
Java EE/Jakarta EEの現状と将来―クラウドネイティブ時代にJava EEは対応できるのか?―
takakiyo
1
120
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.7k
EMとして2023年度に頑張ったこと / What we did well in FY2023 as a EM
pauli
1
130
複雑な構成要素を持つUIとの向き合い方 〜新・支出グラフでの実例〜 / B43 TECH TALK
nakamuuu
0
130
プロトタイピングによる不確実性の低減 / Reducing Uncertainty through Prototyping
ohbarye
5
370
2024/4/26 コンピュータ歴史博物館解説告知
toshi_atsumi
0
210
Postman v10リリース後を振り返る
nagix
0
170
レガシーをぶっ壊せ。AEONで始めるDevRelの話 / Qiita Night 2024-2-22
aeonpeople
3
1.2k
WebアプリケーションにおけるPDOの使い方入門 / phpcon odawara 2024
meihei3
2
440
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
60
14k
How to name files
jennybc
64
93k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
77
42k
Visualization
eitanlees
135
14k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
186
16k
Debugging Ruby Performance
tmm1
70
11k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
24
2.3k
No one is an island. Learnings from fostering a developers community.
thoeni
14
2.1k
BBQ
matthewcrist
80
8.8k
Producing Creativity
orderedlist
PRO
336
39k
Faster Mobile Websites
deanohume
297
30k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
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/