Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Transforming Front-end
Disaster Code™ Into a
Maintainable Masterpiece



@dangribbin
Hi, I’m Dan Gribbin
Software Engineer

brand networks

Web Development Teacher
rochester brainery
front end
js + css + html
design is critical to the
development process
.psd
design (a plan)
best available solution
| constraints
get requirements → write code → ship?
get requirements → write code → ship?
no.
plan system→ then write code
yep
disaster!
alpine
alpine

*internal name - not actual thing name
initial launch
- tight deadlines

- limited front-end resources
- good
- fast
- cheap

(pick two)
our plan lacked detail it
needed for the
future of the front-end
Technical Debt
poor engineering complicates
future work
software entropy
complexity will increase unless
an effort is made against it
we set our front end
up for failure
alpine launch → SDLC
2 week sprints


requirements → code →release
sprint : function() {
technicalDebt++;
},
performance
page load times
15 seconds
:(
poor engineering →
poor user experience
effects on our page load
- render-blocking scripts
- loading all resources on all pages
- lots of code, no minification

maintainability
Time and ease of…
- fixing a bug

- developing a new feature
impact?
↑ feature work dev time
↓ velocity
costs of an unmaintainable codebase to
you and your stakeholders
- time
- money
- frustration
influences on maintainability

JS
- globals

- intermixed functionality
SASS/CSS
- long, overly specific selectors
- confusing naming conventions
- Styles not logically separated

- Hitting IE9 selector limit
morale
entropic products affect the
teams that work on them
our software problems don’t
just belong to one person
your disaster is your team’s
disaster too.
disasters affect morale
(relationships), motivation,
and productivity
initial fixes
initial fixes
… mostly unsuccessful
:/
we needed a do-over
1UP
design!
neptune
much of our JavaScript wasn’t
terrible, just terribly organized
reorganization was top priority
separation, actually
MVC
Some MVC frameworks
ember, backbone, angular, knockout, dojo, YUI, CanJS, Maria, Polymer, React, cujo,
Montage, Ext, Sammy...
MVC frameworks
ember, backbone, angular, knockout, dojo, YUI, CanJS, Maria, Polymer, React, cujo,
Montage, Ext, Sammy, Sta...
constraints
time + experience
AMD + RequireJS
define([’controllers/article-controller.js’],
function(ArticleController) {
ArticleController.init();
}
);
neptune’s front end stack
results
cut page load time by 80%
cut JS per-page by 70%
cut CSS per-page by 75%
-huge maintainability gains
-framework for future work
-testable code
where did we suck?
estimation.
seriously. ouch.
awesome team-building
experience
Things you can do right
now to clean up your
front end
Cleaning up means…
-optimizing for performance
-promoting maintainability
-ensuring reliability
optimize for performance
developer tools are your
best friends
using an image sprite?
you should be!
!

one request → all your icons
no <script>’s in your <head>
<head>
<title>Bad Ideas, Inc.</title>
<script src=“main.js”></script>
</head>
Instead…
…
<script src=“main.js”></script>
</body>
get some help optimizing
use a build tool
In the beginning, was

make
then, this guy stuck
his nose in
a challenger
appears?
which one should
you use?
whichever
one makes
you happy.
minimize and defer
resource loading
!
track down unused CSS
grunt-uncss
gulp-uncss
minify & combine
grunt-contrib-concat
grunt-contrib-uglify
!

gulp-uglify
gulp-concat
optimize images
grunt-contrib-imagemin
gulp-imagemin
!

or, use an app like ImageOptim
for manual operations
cache jQuery selections in your code
var galleryItems = $(‘.gallery-item’)

http://training.bocoup.com/screencasts/the-imp...
promoting maintainability
a hallmark of a maintainable
codebase is organization
short term fixes
Check your styles
using less/sass?

be careful of the nesting trap.
instead of
!

li {
display: block;
}
!

li img {
width: 50px;
}
you can write
!

li {
display:block;
!

img {
width: 50px;
}
}
which is awesome! but be careful.
the following Disaster SASS™
is real code pulled from alpine



viewer discretion is advised
body.single {
.outer-wrapper {
#content{
#content_column{

ul {
li{
a{
img {
width: 50px !important;
}
}
}
}
}
}
}
}
which compiles to…
body.single .outer-wrapper #content #content_column ul li a img
{
width: 50px !important;
}
to override that, we’d need a selector
with a higher specificity and importance
see how this might get
out of hand quickly?
what if all your styles were so
messy? ours were.
how about this instead?
.gallery img {
width: 50px;
}

readable, reusable, maintainable
also, don’t use !important
if you need !important, you
have bigger problems to solve
Collaborate on a
standards document
helpful for getting the entire team
thinking about quality and consistency
involvement increases buy in
collaboration can be an effective
and positive teamwork experience
long term goals
organization through separation
(and avoiding their opposites)
modularize
JavaScript - AMD / MVC

CSS - SASS/LESS
modular code will help you
create extensible features
enforce separation of:
-style
-presentation
-behavior
use class names for on-the-fly
style adjustments
.addClass(‘error’)
instead of
.css(‘border’, ‘red’)
✓ reusable
✓ consistent
✓ maintainable

o/
keeping JavaScript out of HTML means only
having to look in one filetype
el.on(‘click’, doThing)

instead of
onclick=“doThing()”
navigating stakeholder relations
clear, understandable communication
how is what you’re saying relevant to business goals?
the quicker solution will often
lead to more cost down the road
negotiation
great client relationships
are possible!
remember
this is effort against
complexity
making effort against complexity benefits:

- you

- future you
- your team
- your stakeholders
make future-you
love past-you
the perfect
!

tool/framework/library
!

does not exist
plan & design software
for the situation at hand
thanks!
slides here: @dangribbin
Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Upcoming SlideShare
Loading in …5
×

Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece

10,494 views

Published on

A story about what happens when you don't design your front end for the future, and how it make it better when things get messy.

Published in: Technology
  • Be the first to like this

Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece

  1. 1. Transforming Front-end Disaster Code™ Into a Maintainable Masterpiece 
 @dangribbin
  2. 2. Hi, I’m Dan Gribbin Software Engineer
 brand networks Web Development Teacher rochester brainery
  3. 3. front end js + css + html
  4. 4. design is critical to the development process
  5. 5. .psd
  6. 6. design (a plan)
  7. 7. best available solution | constraints
  8. 8. get requirements → write code → ship?
  9. 9. get requirements → write code → ship? no.
  10. 10. plan system→ then write code yep
  11. 11. disaster!
  12. 12. alpine
  13. 13. alpine *internal name - not actual thing name
  14. 14. initial launch - tight deadlines
 - limited front-end resources
  15. 15. - good - fast - cheap (pick two)
  16. 16. our plan lacked detail it needed for the future of the front-end
  17. 17. Technical Debt poor engineering complicates future work
  18. 18. software entropy complexity will increase unless an effort is made against it
  19. 19. we set our front end up for failure
  20. 20. alpine launch → SDLC 2 week sprints
 requirements → code →release
  21. 21. sprint : function() { technicalDebt++; },
  22. 22. performance
  23. 23. page load times 15 seconds :(
  24. 24. poor engineering → poor user experience
  25. 25. effects on our page load - render-blocking scripts - loading all resources on all pages - lots of code, no minification

  26. 26. maintainability
  27. 27. Time and ease of… - fixing a bug
 - developing a new feature
  28. 28. impact?
  29. 29. ↑ feature work dev time ↓ velocity
  30. 30. costs of an unmaintainable codebase to you and your stakeholders - time - money - frustration
  31. 31. influences on maintainability JS - globals
 - intermixed functionality
  32. 32. SASS/CSS - long, overly specific selectors - confusing naming conventions
  33. 33. - Styles not logically separated
 - Hitting IE9 selector limit
  34. 34. morale entropic products affect the teams that work on them
  35. 35. our software problems don’t just belong to one person
  36. 36. your disaster is your team’s disaster too.
  37. 37. disasters affect morale (relationships), motivation, and productivity
  38. 38. initial fixes
  39. 39. initial fixes … mostly unsuccessful :/
  40. 40. we needed a do-over
  41. 41. 1UP
  42. 42. design!
  43. 43. neptune
  44. 44. much of our JavaScript wasn’t terrible, just terribly organized
  45. 45. reorganization was top priority
  46. 46. separation, actually
  47. 47. MVC
  48. 48. Some MVC frameworks ember, backbone, angular, knockout, dojo, YUI, CanJS, Maria, Polymer, React, cujo, Montage, Ext, Sammy, Stapes, Epitome, soma, DUEL, Kendo UI, PureMVC, Olives, Plastron, Dijon, rAppid.js, Deft, Aria, Exoskeleton, Atma, Ractive, ComponentJS
  49. 49. MVC frameworks ember, backbone, angular, knockout, dojo, YUI, CanJS, Maria, Polymer, React, cujo, Montage, Ext, Sammy, Stapes, Epitome, soma, DUEL, Kendo UI, PureMVC, Olives, Plastron, Dijon, rAppid.js, Deft, Aria, Exoskeleton, Atma, Ractive, ComponentJS was one of these right for us?
  50. 50. constraints time + experience
  51. 51. AMD + RequireJS define([’controllers/article-controller.js’], function(ArticleController) { ArticleController.init(); } );
  52. 52. neptune’s front end stack
  53. 53. results cut page load time by 80% cut JS per-page by 70% cut CSS per-page by 75%
  54. 54. -huge maintainability gains -framework for future work -testable code
  55. 55. where did we suck?
  56. 56. estimation. seriously. ouch.
  57. 57. awesome team-building experience
  58. 58. Things you can do right now to clean up your front end
  59. 59. Cleaning up means… -optimizing for performance -promoting maintainability -ensuring reliability
  60. 60. optimize for performance
  61. 61. developer tools are your best friends
  62. 62. using an image sprite? you should be! ! one request → all your icons
  63. 63. no <script>’s in your <head> <head> <title>Bad Ideas, Inc.</title> <script src=“main.js”></script> </head>
  64. 64. Instead… … <script src=“main.js”></script> </body>
  65. 65. get some help optimizing use a build tool
  66. 66. In the beginning, was make
  67. 67. then, this guy stuck his nose in
  68. 68. a challenger appears?
  69. 69. which one should you use?
  70. 70. whichever one makes you happy.
  71. 71. minimize and defer resource loading !
  72. 72. track down unused CSS grunt-uncss gulp-uncss
  73. 73. minify & combine grunt-contrib-concat grunt-contrib-uglify ! gulp-uglify gulp-concat
  74. 74. optimize images grunt-contrib-imagemin gulp-imagemin ! or, use an app like ImageOptim for manual operations
  75. 75. cache jQuery selections in your code var galleryItems = $(‘.gallery-item’) http://training.bocoup.com/screencasts/the-importance-ofcaching-jquery-selections/
  76. 76. promoting maintainability
  77. 77. a hallmark of a maintainable codebase is organization
  78. 78. short term fixes
  79. 79. Check your styles using less/sass? be careful of the nesting trap.
  80. 80. instead of ! li { display: block; } ! li img { width: 50px; }
  81. 81. you can write ! li { display:block; ! img { width: 50px; } }
  82. 82. which is awesome! but be careful.
  83. 83. the following Disaster SASS™ is real code pulled from alpine
 
 viewer discretion is advised
  84. 84. body.single { .outer-wrapper { #content{ #content_column{
 ul { li{ a{ img { width: 50px !important; } } } } } } } }
  85. 85. which compiles to… body.single .outer-wrapper #content #content_column ul li a img { width: 50px !important; }
  86. 86. to override that, we’d need a selector with a higher specificity and importance
  87. 87. see how this might get out of hand quickly?
  88. 88. what if all your styles were so messy? ours were.
  89. 89. how about this instead? .gallery img { width: 50px; } readable, reusable, maintainable
  90. 90. also, don’t use !important if you need !important, you have bigger problems to solve
  91. 91. Collaborate on a standards document
  92. 92. helpful for getting the entire team thinking about quality and consistency
  93. 93. involvement increases buy in collaboration can be an effective and positive teamwork experience
  94. 94. long term goals
  95. 95. organization through separation (and avoiding their opposites)
  96. 96. modularize JavaScript - AMD / MVC
 CSS - SASS/LESS
  97. 97. modular code will help you create extensible features
  98. 98. enforce separation of: -style -presentation -behavior
  99. 99. use class names for on-the-fly style adjustments
  100. 100. .addClass(‘error’) instead of .css(‘border’, ‘red’)
  101. 101. ✓ reusable ✓ consistent ✓ maintainable o/
  102. 102. keeping JavaScript out of HTML means only having to look in one filetype
  103. 103. el.on(‘click’, doThing) instead of onclick=“doThing()”
  104. 104. navigating stakeholder relations
  105. 105. clear, understandable communication how is what you’re saying relevant to business goals?
  106. 106. the quicker solution will often lead to more cost down the road
  107. 107. negotiation
  108. 108. great client relationships are possible!
  109. 109. remember this is effort against complexity
  110. 110. making effort against complexity benefits: - you
 - future you - your team - your stakeholders
  111. 111. make future-you love past-you
  112. 112. the perfect ! tool/framework/library ! does not exist
  113. 113. plan & design software for the situation at hand
  114. 114. thanks! slides here: @dangribbin

×