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
810
ReactiveConf: Lessons Migrating Complex Software
jackfranklin
0
470
Front Trends: Migrating complex software
jackfranklin
1
810
Migrating from Angular to React: Manc React
jackfranklin
1
170
Half Stack Fest: Webpack
jackfranklin
4
540
FullStackFest: Elm for JS Developers
jackfranklin
1
230
Codelicious: Intro to ES2015
jackfranklin
0
370
PolyConf: Elm for JS Developers
jackfranklin
0
280
Other Decks in Technology
See All in Technology
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.5k
dbt開発 with Claude Codeのためのガードレール設計
10xinc
2
1.3k
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
230
データ分析エージェント Socrates の育て方
na0
5
1.3k
「Linux」という言葉が指すもの
sat
PRO
4
140
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
850
Oracle Cloud Infrastructure IaaS 新機能アップデート 2025/06 - 2025/08
oracle4engineer
PRO
0
100
2つのフロントエンドと状態管理
mixi_engineers
PRO
3
110
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
370
AIエージェント開発用SDKとローカルLLMをLINE Botと組み合わせてみた / LINEを使ったLT大会 #14
you
PRO
0
130
バイブスに「型」を!Kent Beckに学ぶ、AI時代のテスト駆動開発
amixedcolor
2
580
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
120
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.8k
The Language of Interfaces
destraynor
161
25k
Become a Pro
speakerdeck
PRO
29
5.5k
Six Lessons from altMBA
skipperchong
28
4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
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/