Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece
Upcoming SlideShare
Loading in...5
×
 

Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece

on

  • 4,639 views

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.

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.

Statistics

Views

Total Views
4,639
Views on SlideShare
4,631
Embed Views
8

Actions

Likes
0
Downloads
14
Comments
1

2 Embeds 8

https://twitter.com 7
https://tweetdeck.twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece Presentation Transcript

  • 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, Stapes, Epitome, soma, DUEL, Kendo UI, PureMVC, Olives, Plastron, Dijon, rAppid.js, Deft, Aria, Exoskeleton, Atma, Ractive, ComponentJS
  • 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?
  • 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-importance-ofcaching-jquery-selections/
  • 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