Learn how to make an application production ready, including all the steps from testing to deployment.
- [Instructor] After my course, building a slack bot with node.js Microservices was done, I knew that the final result was very complete and served its purpose. However, I also knew that they had to make a few compromises to not overload the content. But that's not so bad, right? This also happens in real projects. You know that what you created is good to demo to a client but still not perfect. It's still in development stage and there are a few things to accomplish before going into production. It's just not quite ready to release it to a broader audience.
Now imagine this. Our client agreed that he likes our bot so far and that he wants to go live with it as soon as possible. That means we have some work to do. During this course we will first add version control through Git and we will add a few a few iterations in Vox through our code to find things that could be done better. At the same time, we will create tests and make sure that we don't break things while improving our code. To the improved code base we will then add a few more features and finally, we will explore how to properly and continuously deploy our bot and our services to make future changes easy, fun and free of bad surprises.
When people are writing software today they often don't anticipate that this code may live on for a very long time. I, for instance, am sometimes confronted with code I wrote over 10 years ago, and often I'm struggling to find out why I did things the way I did. There are certain principles I try to follow that make it easier for other developers or my future me to understand and maintain the code I wrote. Some are taken from the book "The Pragmatic Programmer, From Journeyman to Master" by Andrew Hunt and David Thomas. I highly recommend reading it.
One of those principles is don't repeat yourself, or DRY. Every logic, every piece of configuration or knowledge should only exist exactly one time in a project. Any time you have to make the same change in multiple places, you know that your code isn't DRY. During the course we wills strive to have single sources of truth and that our code is free from redundancies and code duplication. Another important principle is keep it simple stupid, or KISS. As Wikipedia says KISS is an acronym for keep it simple stupid as a design principle noted by the US Navy in 1960.
The KISS principle states that most systems work best if they're kept simple rather than made complicated. Therefore, simplicity should be a key call in design and unnecessary complexity should be avoided. This means if there is an easy way to accomplish something and another maybe more challenging and interesting way, one should rather stick to the simple solution, and maybe take a note to explore the other option when there is more time to dive into. Bi code has no mechanical moving parts that can age. Additions to code and maintenance can cause code to lose its quality, until it gets unmaintainable and broken.
Maybe the main reason for that are so-called broken windows. Let me explain that. Studies show that if there is a building, let's think of a house with flats. It will stay in a good shape until something breaks, maybe a window. If this window isn't fixed within a reasonable time, people living in this house will stop to care. Other windows will break, graffiti will spread over the walls, trash will be thrown into the corridors, long story short, the building will corrode away. The same can happen to code.
The day you start adding careless fixers, ignoring proper code style and the structure of the whole application, just to get things done somehow, is the day where your application is doomed. Any other developer or yourself will be increasingly careless while making changes, until everything that is left is an unmaintainable mess. Sometimes it happens to me that I add code that I know isn't perfect but I just can't find a way to make it right. But every time that happens, I revisit the code on the next day with fresh eyes, and usually it's easy to do it right then.
As developers we should be proud of the code we release. Let's strive to achieve that for our slack bot now.
- Adding debugging
- Getting started with refactoring
- Transforming slack-client into a class
- Creating a test infrastructure with Mocha, Should, and Istanbul
- Creating tests for the service registry
- Setting up continuous integration with Codeship
- Adding automated security audits with Snyk
- Adding endpoint security
- Setting up your servers for deployment