I'm super excited right now. It's Saturday morning of memorial day weekend right, and yesterday I had an interview with a rapid growing music-related tech company. They have a really awesome office in the Chelsea market area of New York City. Everyone has a huge iMac at their desk along with a Macbook Pro (well you can choose but it seems like 99% of people prefer mac there). Oh by they way, your desk is a standing desk with power controls to adjust it up or down. As an Angular developer you get to use WebStorm (I'm assuming I would, the interviewer used IntelliJ which is basically just a more features / languages version of WebStorm). Tons of free snack, drinks, and a pretty cool espresso machine that I got a chance to use, a cool outdoor terrace, and ping pong tables all made it this seem like a surreal workplace. I even saw a little nook that had a Nintendo 64 set up with Goldeneye in it! But this post isn't about how great it would be to work at this company; it's about how the front-end teams of today and tomorrow can use principles from the Java era to craft seemingly bulletproof code.
Refactoring - Improving the Design of Existing Code - Martin Fowler - This is, as the title suggests, a book about refactoring. Here Fowler presents a list of code smells, which are suboptimal ways of writing certain code, along with a corresponding refactoring, or prescription for how you can improve the code to be written the optimal way. Interestingly, Fowler clearly states that before you begin truly doing these refactorings the first step is to "get it under test", which is pretty much the subject of the entire Michael Feathers book. Once you do get the existing code under test this book will become important for continually improving the code. It's especially helpful if you are working with other programmers and are responsible for their work. Some people can get uncomfortable if you change their code, and even more so if you are changing their code a lot. You can't tell them that it sucks straight to their face even if it does, but if you have a listing of code smells and refactoring that everyone agrees on up front then we'll have this objective reasoning for making changes, and then together we can gradually transform it into better code.
There is another huge advantage in Angular which is overlooked by most development teams- protractor. Protractor is a tool for e2e tests. It automates manually pushing buttons on the page to make sure things work or to check that your backend developer is actually sending the right thing. This is quite different from unit testing and many will consider this selenium-based testing the domain of someone else (like qa testers), but I am comfortable writing protractor tests and think it can be a very useful tool for programmers while developing. While unit tests are concerned with the actual functions of your applications, protractor tests poke things on the page and make sure the DOM updates as expected.
I'm not even sure if this company will give me the opportunity to come in and take on this project yet, but this really is the type of thing I want to do right now. The project would be for a contract role paying a very good hourly rate but only for three months. That means I have to hit the ground running- hard. I really can't wimp out and forget about the tests. I want to do this project the right way, have it end with glory and confetti, and they go on my way to another tech titan who needs me to slay an Angular legacy code dragon. If I am able to slay the dragon, I think I'll contribute to the creation of a ton of successful software and have a lot of fun doing it.
The posts on this site are written and maintained by Jim Lynch. About Jim...