Transforming Front-End Disaster Code™ Into A Maintainable Masterpiece

8,715 views
8,544 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
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
8,715
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
17
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

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

×