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.
Two Books to Note
Working Effectively with Legacy Code - Michael Feathers - This is a legendary programming book. Basically, it teaches you how to take a bunch of code with no unit tests and wrangle it down under the unit tests. This is basically exactly what they want me to do at this company (I'm not really sure if they know it yet haha), and if you get hired on an already started project this is how you should be thinking about it. They have an existing AngularJS application, but they want to take it to the next level. Perfect. If they hire you they you can choose to go about it pretty much any way you want. But I believe that Feathers's way is the best way, and it's the way I'm going to try to do. It's easy to fall back on the gulp serve crutch and run through an entire application in a day, but if you don't do what Michael Feathers says then your code will rot, the users will see bugs, the software will be mediocre and hard to change; the list goes on and on. Switching between the mindset of writing tests and building an application is tough, but it's what TDD is all about. I can't wait to go back to my parents' house this weekend and get this book so I can read through it again. One slight challenge for an Angular developer might that this book is written with examples in Java and I think even C++. This is can be difficult to translate into Angular's JavaScript dependency injection style of coding, but you can still get a lot out of the book with following along with every line of the code examples. This book teaches you how to take a codebase with no unit tests and get it under test so that you can build off of it with the confidence that the code is clean and works properly.
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.
Why Angular?
At this point in time Javascript is somewhat of the default technology. Companies are making amazing stuff in browsers on all devices, desktop applications, mobile apps, 3D games, and even enterprise level servers all in Javascript! With Javascript you can make beautiful things on all platforms that are fully interactive. Angular extends HTML with a powerful templating system, provides dependency injection for your JavaScript code, and handles a lot of things you would expect from a SPA framework. Angular has a steep and long learning curve, but if you read blogs posts from hardcore JavaScript developers they'll almost always say Angular has the easiest syntax. It's easy to do things wrong (or at least just following bad style practices), but the point is that you can get beautiful web applications up on the page pretty quickly, and it lends itself well to the sort of get-it-under-test mentality of these authors. Also, because Angular has the nicest looking syntax it's inherently very strong in terms of readability and maintainability, a crucial piece to preventing code rot. The way I see it, I already have the challenge of building this incredibly complex thing that the company wants- why tax my self even further by using a complex and potentially buggy JavaScript framework that's not Angular? I want to make low level part as easy as I can on myself so that the code can be as simple, maintainable, and readable as possible.
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.
A Legacy Code Warrior
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.
RSS Feed