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
180
Components on the Web: Frontend NE
jackfranklin
1
690
ReactiveConf: Lessons Migrating Complex Software
jackfranklin
0
390
Front Trends: Migrating complex software
jackfranklin
1
700
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
cgroup v2 で何が変わったのか / TechFeed Experts Night #28
tenforward
2
160
iThome2024 Wailing Wall of Enterprise Security
notsurprised
0
290
LLM評価の落とし穴~開発者目線で気をつけるポイント~
rishigami
11
3.2k
生成AI活用推進の為にやったこと/やらなかったこと
ktc_wada
0
160
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
170
ハードウェアを動かすTypeScriptの世界
9wick
3
1.2k
エンジニアゼロの組織から内製開発の DX をどう実現したのか / How did we achieve DX in in-house development in an organization with zero engineers?
genkiogasawara
7
3k
Dungeons and Dragons and Rails
joelq
0
230
能動学習のいろは:書籍「Human-in-the-Loop機械学習」3〜5章
hiroyoshiito
0
290
【TSkaigi】2024/05/11 当日スライド
kimitashoichi
14
4k
シンプルなHITL機械学習と様々なタスクにおけるHITL機械学習
naohachi89
0
320
データ分析力を高めるSQL研修サービス『SQL Everyone』
hikarut
1
390
Featured
See All Featured
Bash Introduction
62gerente
605
210k
Why Our Code Smells
bkeepers
PRO
331
56k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
47k
Raft: Consensus for Rubyists
vanstee
133
6.3k
Product Roadmaps are Hard
iamctodd
45
9.8k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
Infographics Made Easy
chrislema
238
18k
KATA
mclloyd
16
12k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
9
1.3k
Mobile First: as difficult as doing things right
swwweet
217
8.6k
Teambox: Starting and Learning
jrom
128
8.4k
Designing with Data
zakiwarfel
96
4.8k
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/