JavaScript You Can Live With

We all know that the JavaScript we write today is code we’ll need to tweak or extend tomorrow. The reality is that developers implementing user interfaces, like most software developers, spend 75% of their time in extending or modifying (and, occasionally, fixing) existing code. You can write your code to support that reality or you can make that 75% of your implementation life more difficult.
While you’ll never have to write a code base as big as the ones driving the Amazon and Google sites, there are techniques and tools you can adopt from those teams that will lower your maintenance time while still letting you deliver results quickly. This session will discuss the tools, tactics, and strategies to achieve that.
What you’ll learn:
Tactics and strategies for creating maintainable code
How to structure your code to support evolution but still deliver results rapidly
Tools and techniques to implement Vogel’s law (“You don’t screw with working code”) by always adding new functionality through writing new code
What tools can reduce the cost of making changes to existing user interfaces

Transcript

1. JavaScript You Can Live With Writing code like Amazon and Google developers #livingwithJS
2. Hi! I’m Peter  peter.vogel@phvis.com  @phvogel  http://blog.learningtree.com/category/ux/  PH&Vinformation services 2
3. What’s Your Job? 3
4. The Problems  Trying to insert new functionality  You’re usually modifying an existing page  Figuring out where to make the change  And, of course, what the change should be  Making a change  Without three other things blowing up 4
5. My Assumptions  You don’t have time/support to  Learn a new technology  Change your whole development style  You’d prefer to enhance what you’re doing now 5
6. What I’m Going to Do  Tweaks to what you do (3)  Things you can consider enhancing (5)  REVOLUTION! (3)  Two shameless plugs AND Finish with a hashtag, a haiku, and a Beatles quote 6
7. My Family My Dog 7
8. ego.com  Compulsive reader  Independent consultant: PH&V Information Services  19 years without a job  Technical writer/editor  UX designer  Instructor/Instructional designer  30+ years writing code 8
9. Clients 9
10. Shameless Plug for Me 10
12. Tweaks to What You Do Writing code like Amazon and Google Developers
13. The Fundamental Changes  Code is not “a means to an end”  Code is a resource for the organization  You don’t screw with working code (family version) 13
14. Code is Not English  Inherently difficult to read  You must avoid “expedient” code  That only gets the job done  Write for the “next programmer”  Who, in six months, will be you 14
15. 1. Write to be Read  Write your code expressively EloquEnt CodE, literate code , readable code Really Obvious Code ROC Rocks! 15
16. AND The Difference Between $(function () { $("#txtFN").keyup(clear); var FirstNameTextBox = $("#txtFirstName") $(function () { FirstNameTextBox.keyup(clearEverythingButNames); 16
17. 2. Comments  At least, not inside functions  Don’t try to fix the problem with English sentences  Comments are an apology for unreadable code  What you should now consider bad code  Comments either  Repeat what the code should say (redundant)  Disagree with the code (ruinous)  Only useful if  Complete, accurate and maintained  Comments take time away from writing good code : Don’t 17
18. Comment on Functions  Comment why you felt you need this function  Better Yet: Give the function a very good name  Write to express your intent 18
19. AND The Difference Between $(function () { // On keyup call clearNames function (or clearOther) FirstNameTextBox.keyup(clearNames); LocationTextBox.keyup(clearLocation);} //When user enters some search criteria, we’ll clear the other criteria not chosen $(function () { FirstNameTextBox.keyup(clearEverythingButNames); LocationTextBox.keyup(clearEverythingButLocation);} 19
20. 3. Coding Styles  Have one  Develop lots of conventions  Follow them rigidly  Adopt/adapt your development tool’s conventions  First reason:  Just like UX design patterns tell users what to do next  Conventions tell the next programmer about your code  Second Reason:  Makes you think about how you’re writing your code  Instead of what you want it to do  Third reason  Makes deviations stand out 20
21. AND The Difference Between //When user enters some search criteria we’ll clear the //other criteria not chosen $(function () { FirstNameTextBox.keyup(clearEverythingButNames); LocationTextBox.keyup(clearEvrythingButLocations);} //When user enters some search criteria // we’ll clear the other criteria not chosen $(function () { FirstNameTextBox.keyup(clearEverythingButNames); LocationTextBox.keyup(clearEverythingButLocation); } 21
22. What You Could Consider Writing code like Amazon and Google Developers
23. 1. Use a Tool to Check Your Code  Yes, you’ll lose time getting/integrating it, learning what its’ telling you  You’ll get all back in the first 200 lines of code 23
24. Tools to Check Your Code  ESLint  To look for errors and common mistakes 24
25. And Check Your Style, Too  JSCS  To enforce your coding style  Comes with presets: Adopt one 25
26. 2. Live and Die by the SRO  Single Responsibility Principle  Each function does one thing and one thing well  Each prototype/object does one thing and one thing well  If you have a function more than 30 lines long  You probably don’t know what it’s doing  A 15 line function is automatically better than a 30 line function  Fallout: Lots and lots of simple objects/protoypes 26
27. AND The Difference Between $(function () { $("#txtFN").keyup(clear); $("#txtLastName").keyup(clearNotNames); $("#txtStudentID").keyup(clearNotStudentId); $("#cmbOffice").change(clearNotOfficeList); $("#btnClearForm").click(clearForm); $("#btnSearchByName").click(studentSearch); hideResults(); clearNames(); clearStudentId(); clearOfficeList(); hideResults(); var searchTermOffice = $("cmbOffice").val(); $.getJSON(url + searchTermOffice, processStudents); hideResults(); var fname = $("#txtFirstName").val(); var lname = $("#txtLastName").val(); var oname = $("#cmbOffice").val(); var sId = $("#txtStudentID").val(); if (oname != "") { var localUrl = url + "ByOffice" + "/" + oname; } else if (sId != "") { var localUrl = url + "ById" + "/" + sId; } else { if (fname == "") { fname = "_"; } var localUrl = url + "ByName" + "/" + fname + "/" + lname; } $.getJSON(localUrl, processStudents); switch (students.length) { case 0: displayNoResult(); break; case 1: displayStudentInfo(students); break; default: displayStudentList(students); } }; alert("No matching students found.") $("#studentInfo").show(); var student = students[0]; $("#EmailAddress").html(student.email); $("#ShareName").html(student.networkShare); $("#StudentName").html("<strong>" + student.name + "</strong>"); $("#UserName").html(student.id); var student; var row; $("tr[data-rowstate='added']").remove(); $("#resultTable").show(); for (stu in students) { student = students[stu]; row = "<tr data-rowstate='added'>" + "<td>" + student.name + "</td>" + "<td>" + student.id + "</td>" + "<td>" + student.email + "</td>" + "<td>" + student.networkShare + "</td>" "</tr>"; $("#resultTable").append(row); } $(function () { $("#txtFirstName").keyup(clearNotNames); $("#txtLastName").keyup(clearNotNames); $("#txtStudentID").keyup(clearNotStudentId); $("#cmbOffice").change(clearNotOfficeList); $("#btnClearForm").click(clearForm); $("#btnSearchByName").click(studentSearch); }); function clearForm() { hideResults(); clearNames(); clearStudentId(); clearOfficeList(); } function clearNotNames() { hideResults(); 27
28. 3. Design Patterns  Conventions for structuring code  Assemble complex behavior out of lots of simple pieces  Where you need to do something complicated, write a function that calls other functions  The Façade pattern  Eliminate bugs by eliminating/centralizing logic: if/else, switch  Strategy, role, state, factory 28
29. AND The Difference Between $function studentSearch() { if (oname != "") { var localUrl = url + "ByOffice" + "/" + oname;} else if (sId != "") { var localUrl = url + "ById"...} else { if (fname == ""){ fname = "_"; } var localUrl = url + "ByName" + "/" + fname + "/" + lname; } $.getJSON(localUrl, processStudents); function studentSearch() { var buildUrlForSearch = selectUrlBuilder(fname, lname, oname,sid); var localUrl = buildUrlForSearch(); $.getJSON(localUrl, processStudents); 29
31. 4. Refactor  After It Works: You’re Smarter  So don’t Stop!  Refactor it!  Changes to code that don’t change functionality  But make the code better written 31
33. AND The Difference Between $(function () { FirstNameTextBox.keyup(clearEverythingButNames); LocationTextBox.keyup(clearEverythingButLocation); } $(function () { FirstNameTextBox.keyup(ClearCriteriaNotChosen( FirstNameTextBox)); LocationTextBox.keyup(ClearCriteriaNotChosen( LocationTextBox)); } 33
34. 5. Every Week: Get Knowledge  Set aside one half-hour to not build anything  Instead, learn something you don’t need to finish this page  Learn the language  Work through a book about JavaScript  Most of us just learn what we need for the next piece of functionality  Learn your tool  Google “Cool tip for my development environment” 34
35. Now, He’s Just Being Silly Writing code like Amazon and Google Developers
36. Consider 1. A Databinding Framework + the MVVM Design Pattern 2. Automated Unit Testing (and Test Driven Development?) 3. TypeScript 36
37. 1. MVVM  Model View ViewModel  Alison Tinker called it the Page Object Pattern  ViewModel  JavaScript object with all functionality for a page  Properties for the data/Functions for the actions  Bind the properties to elements  Wire up the functions to the events  Everything happens inside the ViewModel  User enters text: Your property is updated  You change a value: The element is updated 37
39. 2. Automated Unit Tests  Prove your code does what you think it does  Want to test some code?  Set some property (properties)  Call a function  Check some other property (properties)  Only way to reduce the time spent on testing: Don’t test at all  Alison Tinker went one step beyond in her presentation on E2E testing: Testing 1-2-3 39
41. 3. TypeScript  Get the slides from Micheal Szul’s and Ashish Pathak’s presentation: The New JS  Applies conventions built into the compiler  Lets you structure your code expressively  Supports implementing many design patterns  Finds problems as you type them in  Won’t let you run the code until you’ve thought about the problem 41
42. Shameless Plug for One of My Friends 42
43. Summing Up  Really Obvious Code!  Conventions  Comment only for purpose  Single Responsibility Principle + Patterns  Refactor!  Get more tools  ESLint (JSHint), JSCS, KnockoutJS,  Set aside time to learn your language/learn your editor 43
44. The Fundamental Haiku How you write your code Will matter more to you then What your code will do  And, in the end #ROCrox! 44
46. Thank You! peter.vogel@phvis.com @phvogel http://blog.learningtree.com/category/ux/  Don’t forget SpeakerRate  Slides on EdUIconf.org/speakerdeck/sildeshare 46