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
Architecting is Difficult: Breaking Borders, Ap...
Search
Jack Franklin
April 15, 2014
Technology
0
110
Architecting is Difficult: Breaking Borders, April 2014
Jack Franklin
April 15, 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
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
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
11
2.6k
microCMS 最新リリース情報(microCMS Meetup 2025)
microcms
0
250
[CV勉強会@関東 CVPR2025 読み会] MegaSaM: Accurate, Fast, and Robust Structure and Motion from Casual Dynamic Videos (Li+, CVPR2025)
abemii
0
200
イオン店舗一覧ページのパフォーマンスチューニング事例 / Performance tuning example for AEON store list page
aeonpeople
2
360
AIエージェントの活用に重要な「MCP (Model Context Protocol)」とは何か
masayamoriofficial
0
170
AIエージェントの開発に必須な「コンテキスト・エンジニアリング」とは何か──プロンプト・エンジニアリングとの違いを手がかりに考える
masayamoriofficial
0
450
夢の印税生活 / Life on Royalties
tmtms
0
300
LLMエージェント時代に適応した開発フロー
hiragram
1
440
ソフトウェア エンジニアとしての 姿勢と心構え
recruitengineers
PRO
20
9.2k
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
2
310
Microsoft Fabric のネットワーク保護のアップデートについて
ryomaru0825
1
110
スプリントレトロスペクティブはチーム観察の宝庫? 〜チームの衝突レベルに合わせたアプローチ仮説!〜
electricsatie
1
110
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
900
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Docker and Python
trallard
45
3.5k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.5k
Raft: Consensus for Rubyists
vanstee
140
7.1k
How STYLIGHT went responsive
nonsquared
100
5.8k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Side Projects
sachag
455
43k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
830
The Cost Of JavaScript in 2023
addyosmani
53
8.8k
Transcript
Architecting is Difficult
@Jack_Franklin — Student (for one more month) at University of
Bath — (Soon to be a) developer for @GoCardless — Blogger at javascriptplayground.com, tilvim.com — Google Developer Expert on the Chrome team — Does a pretty epic Gangnam Style with @benmacgowan
Any fool can write code that a computer can understand.
Good programmers write code that humans can understand. -- Martin Fowler.
Audience Participation
None
What makes code difficult to work with?
You're never going to get it right first time
Defer concrete decisions as late as possible - you'll never
again know less about the problem than you do right now and the correct abstraction will become clearer over time. -- Andy Appleton
Tests
drive your API design you can try things out at
no cost
difficult to test? difficult to use a good sign something
isn't quite right
confidence when refactoring (more on this later) you'll know when
you broke something
Naming Conventions
There are only two hard things in Computer Science: cache
invalidation and naming things. -- Phil Karlton
There are only two hard things in Computer Science: cache
invalidation, naming things and off by one errors. -- ??
prefer verbosity because auto complete
be consistent use the same nouns and verbs
Coding Standards http://editorconfig.org Pick a standard and stick to it
Single Responsibility
Do one thing And do it well
Not good class EmailSender def initialize(csv) def parse_csv_for_emails def send_email
end
Better class EmailSender def initialize(csv) def parse_csv_for_emails Parser.new(csv).emails def send_email
end class Parser def initialize(csv) def emails end
Decoupled Components
Ye know too much class EmailSender def initialize(csv) def parse_csv_for_emails
Parser.new(csv).emails def send_email end class Parser def initialize(csv) def emails end
Ignorance is bliss class EmailSender def initialize(emails) def send_email end
class Parser def initialize(csv) def emails end emails = Parser.new(csv).emails EmailSender.new(emails).send_email
Separate Aggressively
don't be afraid to create classes / objects It's easier
to merge two small things than split one large thing
Refactoring
None
Refactoring Alter code without changing behaviour You have to have
tests!
Code smells Some code which may indicate a problem
You don't fix code smells. You look at them and
see if they indicate a problem you can fix. -- Joe Ferris
Spot the smell 1
var googleMapPin = function(x, y) {...}; var getLatLong = function(x,
y) {...}; var user = { coordinates: [x, y]; };
Data Clumps Continually passing round two (or more) variables as
arguments.
var googleMapPin = function(coords) {...}; var getLatLong = function(coords) {...};
var user = { coordinates: coords }; var coords = { x: 1, y: 2 };
Implicit Knowledge The relationship of x and y was implicit.
By extracting the coords object, we make it explicit.
Implicit Knowledge Seek to remove all implicit knowledge in a
system. If I was handing it over to you, what would I need to explain?
Spot the smell 2
var drawGraph = function(graphWidth, graphHeight) { var width = 165
+ graphWidth; var height = 170.5 + graphHeight; };
Magic Numbers! 165? 170.2? Implicit knowledge!
var drawGraph = function(graphWidth, graphHeight) { var extra_graph_width_padding = 165;
var extra_graph_height_padding = 170.5; var width = extra_graph_width_padding + graphWidth; var height = extra_graph_height_padding + graphHeight; };
Spot the smell 3
<% if user != nil %> <h2><%= user.welcome_message %></h2> <%
else %> <h2>Please Sign In</h2> <% end %>
Checking for nil (Or undefined / null in JS) What
does nil mean? Nothing.
Checking for nil Don't use it to stand in for
something.
Null Object Pattern Avoids conditional checks.
class GuestUser def welcome_message "Please Sign In" end user =
current_user || GuestUser.new View: <h2><%= user.welcome_message %></h2>
Spot the smell 4
var shouldScrollToBeginning = function(carousel) { if(carousel.isAtEnd()) { carousel.goToStart(); } };
Tell, don't ask This function refers to carousel three times.
Is this the best place for this code?
var carousel = { ... startAgain: function() { if(this.isAtEnd()) {
this.goToStart(); } } }
Tell, don't ask Move the behaviour to where it makes
most sense.
Publish and Subscribe
var carousel = function(accordion) { start: function() { accordion.close(); }
}; var accordion = { ... }
Ye know too much (again) The carousel knows that when
it starts, it needs the accordion to close. That seems a bit odd?
Pub Sub! var carousel = function() { start: function() {
event.publish('carousel_start'); } }; var accordion = { init: function() { event.subscribe('carousel_start', function() { this.close(); }); } }
Pub Sub! Neither module knows about the existance of the
other. Easily extended.
Spot the smell 5
var someMethod = function() { doSomething(); doSomethingMore(); doAnotherThing(); if(something) {
... } doSomethingElse(); while(someOtherThing) { ... } };
Doing too much Functions should be small, reusable and composable.
Spot the smell 6
var carousel = function( width, height, images, arrowLeft, arrowRight, animationSpeed,
loopBackOnEnd ) { ... }
Too many parameters carousel(500, 400, someImages, 'a.left', 'a.right', 500, false);
Try to guess what each of those mean...
Fix one var carousel = function(options) { var width =
options.width; var height = options.height; ... }
But If you need that many arguments, that might indicate
the function is doing too much
Getting into the habit
Everytime you leave code, leave it a tiny bit better
Note: better. Not best.
Don't leave comments #TODO: this entire class is screwed, fix
it #todo REMOVE BEFORE PRODUCTION... SERIOUSLY!
They don't get done 243,803 #TODO comments.
Changing code 1. Refactor to make the change easy. 2.
Make the change Each change should be easy to introduce. If it's not, refactor.
Refactor as you go Should be a constant process of
small improvements.
Remember You can't get it right first time!
URLS — @Jack_Franklin — http://speakerdeck.com/jackfranklin — github.com/jackfranklin/talk-architecting-breaking- borders — http://javascriptplayground.com
— http://refactoring.com/ — http://robots.thoughtbot.com/
(Easy) Questions?