James Shore: Rigorous, Professional JavaScript
James Shore (@jamesshore) was talking about Rigorous, Professional JavaScript at Scotland.js, these are my notes from his talk.
When I started programming I was 20 years old and thought I was convicned that the only thing that mattered was writing great code. Six years later I was leading a team and I had a really interesting experince. We were doing everything right and by the book and then they came up to me and said they were over budget so: "goodbye". The software was shipped and we thought it was what the customer wanted. They found the misplaced budget and I was brought back in. Turns out the software was missing key features because the customer didn't really know what they wanted.
Technology success, business success and personal success are all required for success in software development. However, I was seeing companies having huge success with crap code - really bad code. They were hiring me because they couldn't ship anymore and they were still successful.
Palm were the first great handheld and had the first real smartphone. The first Palm was amazingly fast by modern standards but it got slower and buggier over time. The final version was so bad that even Palm didn't use it! Then they built a new OS called WebOS which was fantastic but got killed by stupid HP corporate politics. This happens over and over - like Netscape.
You can have really bad code and still have success.
- Good business Makes a company.
- Bad technology Breaks a company.
- People Glue the company together.
Preventing the rewrite
Rewrites are caused by technical debt. 25-50% of this is reproducing features you already have. This stops adding new features and you may even have to run two code bases in parallel.
Technical debt
In business debt is a tool so business tends to look at technical debt as a good thing. Technical debt is not good debt, it's like payday loans. Typing on the keybaord creates technical debt. Every decision you make creates technical debt. Constant atention to code quality is the only way to offset this. Refactoring is the key to this.
Refactoring
You can't do refactoring well without good build and test automation. "A good design minimises the time required to create, modify, and maintain the software while achieving its business goals." What I'm talking about is minimising maintainence time, especially at the cost of creation time.
In practice
Language gotcahs
JS has some peculiarities to it. One of the ways round this is to use a static analysis tool such as JSLint or JSHint - equivalent to compilation in other languages. Use a build tool such as Grunt or Jake. Build automation is the foundation of professional JS devleopement. With a single command you should be able to build and test your code such that if it passes it can be shipped.
Lookup: Garry Bernheart: Language gotachs
Cross browser incompatibility
This is a real headache. We have to test everywhere. You have to test everyhwere you want it to work from the beginning. Try a tool called Karma -> runs from the command line and creates a server that captures results from browsers that are connected to it.
"IE8 is mostly likely to have problems. What is your problem? Live demos never work. Last try IE bfore I put you out to pasture. Nope. Now IE9 has gotten confused as well. Live coding always goes wrong."
You need to check that your tests are running in the way you expect. Count the number of tests and check they all ran.
Lots of UI Code
Need to take a much more complicated approach to testing. Front end TDD. TDD is a rapid cycle of writing test code then production code then repeating.
- Think - what's the smallest test can I write that will fail.
- Fail test
- Write production code
- Pass test
- Refactor
- Goto 4 until it's as good as it can be.
- Goto 1.
Each step of this cycle should take around a minute.
Tests should take the form:
- Arrange - set up the test condition.
- Act - run the code to be tested.
- Assert - check the results are what you expect.
- Reset - switch back to a known state.
Don't worry about how the browser or library works - only worry about our code. Do we handle events correctly? Do we manipulate the DOM correctly? Don't test the implementation, test the results. Simulate event -> test DOM.
Pitfalls
Common objection people raise is "is it worth setting all this up?" If you are going to do professional rigorous development you need to do this. It gives you a one button deploy of tested code which is worth investing time into. Your startup time is fairly high but you speed up and maintain that speed. The payoff for this slow start comes after about six weeks. If you don't do this and you are working on a project that is critical for your company then you are taking a loan out from Guido who will come round with the "Rebuild" baseball bat to break your knees later.