Surviving your frontend (WIP - Sneak Peak)
-
Upload
sebastian-schuermann -
Category
Engineering
-
view
321 -
download
2
description
Transcript of Surviving your frontend (WIP - Sneak Peak)
S U R V I V I N G Y O U R F R O N T- E N D
W H A T A M I L L I O N S L O C O F H T M L , J S A N D P H P TA U G H T M E
W H O I S S E B A S T I A N S C H Ü R M A N N
• Coder for about 15 years
• All things agile since 2004
• Agile Coaching, some consulting and freelance development
• http://dissident-trainings.de
W H Y T H I S TA L K ?
I W O R K O N T H I N G S
O F T E N I T S F R O N T- E N D
P E O P L E W I L L B E L I K E . .
– M I C H A E L D E L L
„You don't have to be a genius or a visionary or even a college graduate to be successful. You just
need a framework and a dream.“
V E N N D I A G R A M O F M Y W O R K W E E KR E A L I T Y I S L I K E …
http://cssquirrel.com/
• Specifications are very roughly prepared for front-ends
• The crafty side of development, modularization and testing is neglected
• Standards are not set and/or followed
• The fact that a javascript front-end is the client to a server application is often overlooked
• Front-end code is often thought as throw away.
T H E T H R E E S O L U T I O N V E C T O R S
C R A F T T O O L S
P R A C T I C E S
„ G I V E A S M A L L B O Y A H A M M E R , A N D H E W I L L F I N D T H AT E V E RY T H I N G H E E N C O U N T E R S N E E D S P O U N D I N G . “
A B R A H A M K A P L A N
TOOLS
H I S T O R Y O F J S F R A M E W O R K SA I N C O M P L E T E … . .
jQuery
baconJS
rxJSmootools
prototype
backbone.js
2 0 0 2 2 0 1 4
XUL AngularJS
I W A S O N C E T O L D J Q U E R Y W A S T H E T H I N G … . . I N 2 0 0 6
B U I L D I T
• Repeating tasks by hand is prone to errors
• Build, test and release is complex in 2014
• You want to see the „final“ result
• Fast feedback!
• Make the build FAST!
T E S T I T
• Always be testing
• Using tests is faster than developing in the browser
• Setup is often a pain
• How many browsers do you support?
M O D U L A R I Z E I T !
• Single responsibility
• Different job, different behavior
• Build and test for this component
• CI/CD for this component
• Assets -> Component
S C A F F O L D I T !
• You will be creating a lot of modules/components
• They should follow a consistent structure
• Creating this by hand is error prone and waste of time
R E C R E AT E I T
• A front needs a back(-end)
• I am not a expert in backends per se
• Especially not in your backend
• But I needz it for validation!
M E A S U R E I T
• Analytics is key
• Not only (rendering) speed
• Know your KPI’s
• Is it still working?
• Track errors!
• Can you prove it?
C O N C L U S I O N T O O L S
• Hipster frameworks? Cargo cult?
• Learn and use the tools for automation. Create a „monkey task list“ and automate one task a day
• It’s 2014, you will be testing, get over it!
“ C R A F T S M A N S H I P N A M E S A N E N D U R I N G , B A S I C H U M A N I M P U L S E , T H E D E S I R E T O D O A J O B W E L L F O R I T S O W N S A K E . ”
R I C H A R D S E N N E T T, T H E C R A F T S M A N
CRAFT
T H E S T O R Y O F T H E L O A D I N G I N D I C AT O R !
C O M P L E T E N E S S
J I R A # 1 2 3 5 T H E L O A D I N G I N D I C AT O R I N T H E F R I E N D
S E A R C H I S N O T G O I N G AWAY
$ . A J A X A N D T H E FA L L A C I E S O F D I S T R I B U T E D C O M P U T I N G
C O M P L E T E N E S S
T H E FA L L A C I E S O F D I S T R I B U T E D C O M P U T I N G• The network is reliable.
• Latency is zero.
• Bandwidth is infinite.
• The network is secure.
• Topology doesn't change.
• There is one administrator.
• Transport cost is zero.
• The network is homogeneous.
T H E FA L L A C I E S O F D I S T R I B U T E D C O M P U T I N G• The network is reliable.
• Latency is zero.
• Bandwidth is infinite.
• The network is secure.
• Topology doesn't change.
• There is one administrator.
• Transport cost is zero.
• The network is homogeneous.
1 9 9 4
$ . A J A X A N D T H E FA L L A C I E S O F D I S T R I B U T E D C O M P U T I N G
C O M P L E T E N E S S
T I M E O U T ?
E R R O R ? W H I C H E R R O R E X A C T LY ?
5 0 0 4 0 4
RFC 7231 MOTHERFUCKER
DID YOU READ IT?
2 0 0 4 X X 5 X X
4 1 9 : A U T H E N T I C AT I O N T I M E O U T
J I R A # 1 2 3 5 S O L U T I O N : O N E R R O R C O D E 5 0 0 G O T O
U S E R H O M E ( S E S S I O N I S R E S TA R T E D T H E R E )
T H E S T O R Y O F T H E F O R M VA L I D AT O R
N I H - N O T I N V E N T E D H E R E
J I R A # 1 2 3 6 I M P L E M E N T A VA L I D AT I O N I N
R E G I S T R AT I O N F O R M S O T H AT U S E R S G E T FA S T E R F E E D B A C K I F H O M E
A D D R E S S I S O K
– W I K I P E D I A V I A H T T P : / / W W W. W I K I W A N D . C O M / E N /
N O T _ I N V E N T E D _ H E R E
Not invented here (NIH) is the philosophy of social, corporate, or institutional cultures that avoid
using or buying already existing products, research, standards, or knowledge because of their
external origins and costs. The reasons for not wanting to use the work of others are varied, but
can include fear through lack of understanding, an unwillingness to value the work of others, or
forming part of a wider "turf war"
J I R A # 1 2 3 6 C O M M E N T I M P L E M E N T O W N S O L U T I O N B A S E D O N
R E G E X T O VA L I D AT E F O R M
J I R A # 1 2 3 6 I M P L E M E N T A VA L I D AT I O N I N
R E G I S T R AT I O N F O R M S O T H AT U S E R S G E T FA S T E R F E E D B A C K I F H O M E
A D D R E S S I S O K
D E V E L O P M E N T TA K E S 2 W E E K S
S T R E E T
1 S T R E E T
S T R E E T A / 1A D D I N G A N O T H E R L I B F O R R E G E X P
X - B R O W S E R
N O S T R E E T AT A L L
I PA D Y U N O B L U R ?
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
R F C 8 2 2 E - M A I L A D R E S S F O R M AT
bower search validator | wc -l 43
A R E W R I T T E N M O D U L E
• Passes all the same unit tests and then some.
• Is a demonstrably better solution to the problem addressed by the original
• Makes the developer of the original module go "Ooooo, why didn't I think of that?“
• Has fewer lines.
A R E I N V E N T E D M O D U L E
• Has different (but maybe fewer) bugs.
• Behaves differently (but NOT more correctly) with boundary cases.
• Had code that does things differently for stylistic reasons rather than function.
• May support some lame excuse to have more lines.
T H E S T O R Y O F T H E R E W R I T E
Q U A L I T Y
J I R A E P I C # 5 R E W R I T E A D M I N S I T E A N D A P P F O R
S H O P O W N E R S
2 0 0 9 - 3 M O N T H1 Developer
60 M/D
2 0 1 1 - 4 M O N T H4 Developers
320 M/D
2 0 1 2 - 6 M O N T H6 Developers
720 MD
2 0 1 4 - 8 M O N T H8 Developers
1280 MD
W H Y ?
• Technology changes
• We make mistakes
• We get better & new ideas
• New features (added fast)
• Code rot
• Hurry?
• Wrong specs?
• Saving on QA anyone?
B O Y S C O U T R U L E
A LW AY S B E R E FA C T O R I N G
T H E S T O R Y O F T H E 1 2 0 M E G A B Y T E C H E C K O U T
B I G B A L L O F M U D
D AY 1 AT A C U S T O M E R P R O J E C T
– C I TAT I O N N E E D E D
„Big ball of mud" systems have usually been developed over a long period of time, with
different individuals working on various pieces and parts. Systems developed by people with no formal architecture or programming training often
fall into this pattern“
– C I TAT I O N N E E D E D
„Another reason leading to produce this kind of system is when managers put pressure on
developers and come with incremental micro requirements instead of providing a clear description of the problem to be solved“
– C I TAT I O N N E E D E D
„Foote and Yoder do not universally condemn "big ball of mud" programming, pointing out that this pattern is most prevalent because it works —
at least at the moment it is developed. However, programs of this pattern become
maintenance nightmares“
– C I TAT I O N N E E D E D
„Programmers in control of a big ball of mud project are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it. Technology shifts – such as client-server to web-
based or file-based to database-based – may provide good reasons to start over from
scratch“
O N E G I T C L O N E T O R U L E T H E M A L L
du -hs172M
find . | grep js | grep -v node_modules | grep -v lcov-report | grep -v json | grep -v .git | wc -l 306
find . | grep coffee | grep -v node_modules | grep -v lcov-report | grep -v .git | wc -l 96
file
s: j
ava,
xte
nd,
coff
ee,
js
./aaa/bbb/ccc/ddd/target/classes/js/lib/myClassName.coffee
• Javascript / Coffeescript with close to 0 comments
• JS == no namespaces (header.js vs. header.js)
• 194 Tests
• > 5K Coding style validations
• lcov only for js
• Setup took a day (from 16 billed)
• Fixing „npm test“ another one
• JS Tests not in CI
• NPM install failed at first
D I R T Y T R I C K S• Use small components that do
one job
• Decouple the front-end from backend for development
• keep the integration/master building
• adhere to your fucking standards (or you have none at all)
• Integration and deployment is part of development
• Let the dev change the build chain as well
V S
„ … T H E R E I S T R O U B L E C A U S E D B Y C O N F L I C T I N G M E A S U R E S O F Q U A L I T Y, O N E B A S E D O N C O R R E C T N E S S , T H E O T H E R O N P R A C T I C A L E X P E R I E N C E ”
R I C H A R D S E N N E T T, T H E C R A F T S M A N
PRACT ICES
T O O L S
P R A C T I C E S
C U LT U R E / C R A F T
CONT INUOUS
DEL IVERY
• On every machine
• For every dev
• Build and re-build on CI
• Invest in CI and CD
• Adopt the culture
• This is why a Ops person IN a team is so important
• checkout, build, code, test, commit, deploy, validate (fast)
O N E B U T T O N T E S T
O N E B U T T O N B U I L D
O N E B U T T O N D E P L O Y
R E L E N T L E S S Q U A L I T YN O - C H O I C E
C O S T O F B U G F I X I N G
0
25
50
75
100
Design Implementation Testing Bugfixing
W H Y I S B U G F I X I N G S O E X P E N S I V E ?
• Bugs costs it self
• Other work has to be delayed
• Many departments in loop
• Risk of new bugs 0
25
50
75
100
Design Implementation Testing Bugfixing
T H E C H E A P E S T Q A T O O L S
• Flipchart / Whiteboard
• Stories / Specs
• Specifications derived from examples
• QA is part of the whole development process
W H E R E I S Y O U R B L I N D S P O T ?
Testing quadrant - stolen from @lisacrispin
T H E C F OY O U R B I G G E S T A L LY I N Q U A L I T Y
R E S P O N S I B I L I T Y F O R T H E W H O L E P R O C E S S
F R O M D E S I G N T O D E P L O Y M E N T
( A E X T R E M E ) D E F I N I T I O N O F D O N E
• When tests pass
• When integrated
• When deployable build
• When deployed
• When measurably delivering value
http://www.xpdays.de/2014/downloads/002-extreme-continuous-delivery-at-unruly/cd_javaone.pdf
PA S SR E FA C T O RPA S SD E P L O Y
FA I LF E E D B A C K
T D D D E P L O Y M E N T
http://www.xpdays.de/2014/downloads/002-extreme-continuous-delivery-at-unruly/cd_javaone.pdf
N - A M I G O S
D E V D E S I G N P R O D
O P S Q A
PA R T O F A L L P R O C E S S S T E P S
C O N C L U S I O N SW H A T I L E A R N E D S O FA R ( T )
D E V E L O P Y O U R C R A F T. E V E RY F U C K I N G D AY
L E A R N I N G P H A S E V S . I G O T I T P H A S E
F R O N T- E N D I S F U L L B L O W N S O F T WA R E E N G I N E E R I N G
N O T J U S T A B U N C H O F S C R I P T S
F R O N T- E N D I S F U L L S TA C K
N O T J U S T H T M L 5 + J S
Y O U A R E ( A L L ) R E S P O N S I B L E F O R T H E S U C C E S S
I T S A T E A M T H A N G
I T I S A A M A Z I N G T H I N G ( O R I T S H O U L D B E )
I T S C O O L
T O O L S L E A D T O P R O C E S S E S L E A D T O C U LT U R E A N D C R A F T S M A N S H I P
A N D V I C E V E R S A
– S T E V E W O Z N I A K
The way I did it, every job was A+.
T H A N K Y O U F O R L I S T E N I N G A N D T I M E F O R Q U E S T I O N S !
Sebastian Schürmann http://dissident-trainings.de