DEV Community: Mikhail Levkovsky

Putting the Breaks on Downtime

Mikhail Levkovsky — Thu, 21 Jan 2021 01:09:28 +0000

It comes as no surprise that for any ecommerce business like SSENSE, there are peaks and valleys in terms of customer traffic. There are periods of relative calm, followed by high-traffic periods where we experience up to 80 times the regular traffic. This can come during drops of highly anticipated items — like sneakers — the start of our seasonal markdown periods, and around the holidays.

It should come as even less of a surprise that when dealing with a microservice architecture, you have to pay extra attention to the resiliency of your stack to avoid any downtime. The last thing that any developer wants, is a domino effect of downward dependencies causing downtime of a service that’s 5 levels up.

At SSENSE, we set an extremely aggressive target for ourselves of having a 99.95% yield during these critical moments for the business. Among many steps that we took, handling graceful degradation was key in ensuring we did not experience any downtime during a critical period for the business.

The degraded experiences were broken down into two main strategies:

Automatic degradation
Planned degradation

Automatic Degradation

To automatically degrade our services we leverage circuit breakers. The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error/empty or result/cached result, without the protected call being made at all.

The library we leveraged is called opossum.js, an open source Hystrix compliant library. It's relatively easy to use, and is very configurable. The key attributes that we configured were:

The api timeout: If our function takes longer than this value seconds, trigger a failure.
The error threshold percentage: When this error percentage of requests fail, trigger the circuit.
The reset timeout: How long to wait before trying again.
The rolling count timeout: Sets the duration of the statistical rolling window, in milliseconds. This is how long opossum keeps metrics for the circuit breaker to use and for publishing.
The volume threshold: The minimum number of requests within the rolling statistical window that must exist before the circuit breaker can open.

Although opossum is extremely easy to use, in order to ensure it's adoption internally, we decided to simplify it even more and turn it into a decorator.
This allowed us to wrap our gateway calls in a circuit breaker like so:

To translate this decorator into plain English what it means is that:

If after 3 errors within 10 seconds, we still get response times of 5+ seconds or 55%+ requests fail then open the circuit and call the fallback method. Try one call to the original product-service again after 15 seconds, if it works then close the circuit and go back to normal, if it fails keep the circuit open.

We sprinkled these decorators across our code, and got seamless fallbacks if errors started happening within our stack.

Planned Degradation
The second step we took is to define our planned degradation and what that means for the customer experience. While the automated degradation was mostly decided within the tech team, the planned degradation was a collaboration between tech and product.

Our goal when working on this was: "How can we protect our stack in advance from surges in traffic, by turning off some features while still maintaining an acceptable user experience?"

This was cross functional work with multiple teams, stakeholders, tech leads, and project managers. To be able to roll this out we leveraged a tool that we use extensively at SSENSE: LaunchDarkly. We use LaunchDarkly internally to manage our feature flags to be able to enable/disable features in an instant, either for the whole user base or on a percentage based rollout.

The next part was how to operationalize this in an efficient manner. The questions we had to ask were:

When do we enable these features?
When do we disable these features?
What is the customer impact?
What is the business impact?
What services does this affect?

To answer the first two questions, we broke down our degraded features into three sections:

Go Live: Turned on ~1 hour before a high-traffic event, turned off when traffic dies down.
Amber: Prolonged drop in yield for key funnel services or stack experiencing important latency, but still responsive. Decided in a war room session when to trigger this.
Code Red: If critical flows are down, these feature flags will be activated. Decided in a war room session when to trigger this.

The next three questions were answered by:

Digging into the code to look for dependencies.
Inspecting our traces and flame graphs using Datadog.
Regression testing with our QA team.
Getting buy-in from stakeholders.

After all was said and done, here are a few examples of the planned degraded experiences we decided to go with:

Disable one of our widgets on the product display page (2% decrease in downstream traffic)
Disable our personalization models for the mobile app (decrease latency by 4x-5x)
Disable the counter on the Shopping Bag menu item (74% decrease in downstream traffic)
Display a static message for shipping rates in some use cases (decrease downstream calls by 500K/hour)
Use internal cache of Wishlist items (will continue working even if downstream source of truth is non responsive)
Disable the Order History page

Simplify the order confirmation page

Results

Although these experiences showed a lot of promise during our load tests - with significant increases in throughput - it was time to put them to the test during our high traffic period.

Was all this work worth it?

Well, see for yourself.

While I can't disclose the absolute number of checkouts, this relative graph will show just how much the checkouts grow during a high-traffic period - not including all the other types of traffic we receive. The stack performed flawlessly with no downtime and our YIELD goal of 99.95% was achieved.

The degraded experiences that were baked in are definitely not the only reason we did not experience any downtime. Teams worked and continue to work tirelessly to ensure stability across the stack with a slew of different initiatives to stabilize and improve the resiliency of our stack.

In the end, planning for degradation and handling it properly should be just one strategy in your arsenal when building a resilient product.

Test-Driven Development (TDD) and Why People Get it Wrong

Mikhail Levkovsky — Sun, 01 Mar 2020 19:40:15 +0000

Whether at school, work, or while watching a YouTube video almost every single developer has been introduced to Test-Driven Development, AKA TDD.

For the following examples we will build out a calculator (for simplicity) in Typescript. However, all these principles are language agnostic.

Most tutorials of TDD explain it in more or less the same way:

You receive a completely new feature request
You write the test case
Your test case fails
You write the corresponding code
You run your test again
Your test passes

The code sample might look something like this:

You would then update the method to make it work, ending up with something like this:

Unfortunately, this is where the majority of TDD articles end, which in my opinion, misses the whole point of TDD.

The real magic of TDD comes after the initial features are built in two main use cases:

Bugs: proving that one existed and proving that you fixed it.
Evolution of features and proving that they meet the acceptance criteria.

Bugs

Let's add some more functions to our calculator (and some new tests, of course) with a well-placed bug:

Any seasoned developer (or anybody who has used a calculator before) will see that there is a bug in the subtract method, however, our unit tests still pass. Dang! Looks like our unit test missed a pretty important use case, the fact that it will fail for any value outside of subtracting two zeroes. The initial reaction of any developer - myself included - would be to hop right in, fix the subtract method, and update our unit test.

Well, if you're doing TDD you're actually taking the wrong approach. You're approach should be:

Write a proper test case to prove that the bug exists
Fix the feature
Run the passing test proving that you fixed it

In terms of code changes, it would look something like this:

You would then fix the code and run the tests again:

By doing this two-step process, you not only improve your unit test suite, but you prove from a functional standpoint that you found the bug and resolved it.

Evolution of Features

As requirements and products grow, it's also a great time to remember your TDD best practices.

Let's say your stakeholders come to you and say that they absolutely need a divide function for your calculator application. All the customers are
clamouring for one and you need to develop it ASAP.

If you're not doing TDD, then you might jump right into coding and add the divide function. However, since we are TDD fanboys and girls, the approach will be different.

The steps we will take are:

Add the unit test for division
Run it and have it fail
Program the functionality
Run it and have it pass

Our code changes will look something like this:

Now we add the functionality of division, so our code change will look something like:

The advantage here is two-fold. The first is that you can sit with your PM and define the correct inputs and outputs, and then code against them with confidence. The second, which is one of the more underrated uses of unit tests, is that by writing the unit test first you will be able to see very early on if your code needs to be refactored.

This example is very simple and straightforward, but imagine the unit test was mocking several calls and database connections, and now you had to add an HTTP call. By starting with a unit test, you will be able to tell almost immediately that the unit is getting way too complicated and has too many dependencies. This will allow you to proactively refactor your code and build it in a scalable and testable way.

If you were to start coding first, you would only hit the mocking and dependency roadblock in your unit tests towards the end of the development cycle.

Hopefully this sheds some insight into doing TDD not just at the beginning but throughout the whole product life cycle.

Originally written for https://medium.com/ssense-tech/test-driven-development-tdd-and-why-people-get-it-wrong-9c8b80536838
Editorial reviews Deanna Chow, Liela Touré, & Prateek Sanyal.

Getting Started with Lambda functions, SLS and Node

Mikhail Levkovsky — Mon, 02 Sep 2019 01:20:04 +0000

At work my team had an interesting task of processing certain files daily as they were uploaded to an S3 bucket.
Instead of having an application deployed and perpetually running in the background, we decided to try out AWS Lambda.

This article will give an overview of how we setup our Lambda from beginning to end. I'll review how we manage the cloud formation stack with SLS, explore ways to set it up for different environments, and finally go over its deployment.

First, you'll need a few things:

An AWS account
Node v8.x (at a minimum) installed on your machine
AWS CLI (Command Line Interface) installed on your machine
SLS CLI installed on your machine

In order to manage our Lambda deployment successfully, I decided to use the Serverless Library. This library is extremely powerful and allows us to essentially manage our entire stack with YAML files.

In our use case, we wanted to create an S3 bucket that would trigger a specific method in a Lambda function upon receiving a file. All of this is defined in a few lines of a YAML file. Let's take a look.

First, in our project we added a serverless.yml file with the following parameters:

pssst I tweet about code stuff all the time. If you have questions about how to level up your dev skills give me a follow @mlevkov

The first part of the serverless.yml file establishes some basic requirements (i.e. what region in AWS to deploy, your AWS profile, etc…), the second part is where the fun starts.

This file declares that the s3Handler function inside of the app file will be triggered when a .csv file is created in the mybucket S3 bucket.

The last part of the file declares the plug-ins, which allow us to use TypeScript and run our serverless deployment locally.

To give you an idea of the code that will be processing the files, here is a simplified set of snippets to demonstrate the flow:

app.ts

app/controllers/S3Controller

And what does this deployment look like once it's on AWS?

On the left you have the S3 trigger which is activated when .csv files are uploaded. In the middle you have the jb-recommendation Lambda, and on the right you have your Amazon CloudWatch Logs and the S3 bucket where your Lambda function will be uploaded to.

Deployment

SLS makes deployment easy as pie.

First, let's setup your local AWS profile:

aws configure - profile localdev
AWS Access Key ID [None]: <ENTER YOUR ACCESS KEY>
AWS Secret Access Key [None]: <ENTER YOUR SECRET KEY>
Default region name [None]: <ENTER 'us-east-1'>
Default output format [None]: <ENTER 'text'>

After which, you just run sls deploy and you're good to go.

Environment variables

What we did earlier will deploy your application, but chances are that you'd want some environment specific variables to isolate development, QA, and production environments.

Here's how I recommend introducing these:

The first step is to create a folder called configurations and create 3 separate YAML files:

dev
qa
prod

We won't add anything too complicated to these files, just a change in
the Node environment to ensure that our environments work as expected.

/configuration/dev

NODE_ENV: 'development'
profile: 'localdev'
region: 'us-west-2'
stage: 'dev'

/configuration/qa

NODE_ENV:'qa'
profile: 'qa'
region: 'us-west-2'
stage: 'qa'

/configuration/prod

NODE_ENV:'prod'
profile: 'prod'
region: 'us-west-2'
stage: 'prod'

Now that we have separate environment variables, let's modify our serverless file to use them.

We changed our serverless file to also include custom variables such as stage and configuration. Now when we deploy, we can specify the stage which in turn will select the appropriate configuration file:

To toggle environments, all we have to do is add the -s [env] flag as follows:

sls deploy -s [dev/qa/prod]

The -s stands for the stage you want to deploy.
This will automagically create everything necessary for your entire CloudFormation infrastructure. It creates the S3 bucket, creates the S3 trigger events, deploys our Lambda function (hosted in a different s3 bucket) and adds the cloud formation logs.

With a few YAML files we were able to deploy our Node application, create our S3 buckets, and setup the right events for 3 separate environments. Hopefully this article helps to provide context around when and how to integrate Lambda into your stack.

If you want to level up your coding skills, I'm putting together a playbook that includes:

30+ common code smells & how to fix them
15+ design pattern practices & how to apply them
20+ common JS bugs & how to prevent them

Get early access to the Javascript playbook.

5 easy wins for cleaner Javascript code 🧹

Mikhail Levkovsky — Tue, 27 Aug 2019 04:59:38 +0000

Imagine an empty and clean kitchen sink. It's so shiny you can see your reflection inside of it. If you had a dirty plate, you would probably feel pretty bad just dropping it into the sink, right? You would clean it and put it away.
Now what if your sink is full to the brim, with a bunch of nasty food particles floating around in that nasty water. In that case, you would just throw in your plate because, well, one more plate can't hurt. Unfortunately that is how we treat our code bases as well. Instead of tidying up our code base, we just sometimes throw in more and more code smells.
Well, below are 5 things you can do to start tidying up your code base right now 🚀.

N.B. For some reason, the gists sometimes render in a really weird order. If the code doesn't line up with what I'm writing about, refreshing the page seems to fix it. Sorry about that! 😕

1. Use let and const and forget var

You should no longer be using var, as it can easily introduce variable shadowing and can lead to a lot of confusion. If you need a value that doesn’t change use const. If you need a variable that doesn't change but you will initialize it in the constructor use readonly. If you need a variable who's value does change use let.

pssst I tweet about code stuff all the time. If you have questions about how to level up your dev skills give me a follow @mlevkov

2. Always use string templates

When concatenating strings you should always stick to string templates instead of the concatenation operator. This will make your life much easier as it allows for multiline strings, reduces any errors if your strings have quotes and is generally a lot easier to read. Here is how it would look like when we try to create a database connection string without string templates and with. Think of the kitchen sink. Try to keep your code as tidy as possible.

3. Object shorthand should be used when possible

Javascript and Typescript goes to great lengths to reduce verbosity. One of my favourite things is that when creating an object with keys, you can use the shorthand annotation to assign your variables to the right keys. Let’s look at an example of us creating a user object in a different way.

4. Merge Your Imports

When importing either your own modules or from installed libraries there are certain conventions to follow. Some of them are less important than others. Personally I don’t care if the imports are in alphabetical order or not. However, if you’re importing multiple things from the same module, you should merge them into one. This will keep your code tidy and keep your imports from being all over the place.

5. Loop through your iterables properly

If you have an iterable, such as an array or a list, and you want to go through the values, you should use the for of instead of the for in. You should use the for in if you want to iterate through the properties (e.g. keys in an array) as opposed to the values. Take for example this method in the Playlist object that will list out all of the names.

There you have it, 5 easy tips that you can use to keep your code base nice and tidy.

If you want to level up your coding skills, I'm putting together a playbook that includes:

30+ common code smells & how to fix them
15+ design pattern practices & how to apply them
20+ common JS bugs & how to prevent them

Get early access to the Javascript playbook.

Thinking in Redux (when all you’ve known is MVC)

Mikhail Levkovsky — Tue, 20 Aug 2019 13:44:37 +0000

When rolling out a mobile app, one of the first decisions you usually make is: what language do we use? After some deliberation, and when you come to the realization that you don't want to learn Kotlin and Swift, you finally settle on React-Native. From my own experience, learning a new “language” or framework isn’t a huge issue, but man oh man, did react-native and redux give me a hard time. This article doesn’t explain how React-Native works (as that is not the hard part). The purpose of the next few paragraphs is to help anybody reading this transition from “thinking in MVC” to “thinking in Redux”. Hope it helps.

React-Native and Redux?

As soon as you start learning about react-native (or react), you are about 3 stack overflow questions or medium posts away before somebody mentions redux.
You were so happy. You started to understand state vs props, you know what componentDidMount does and you even understand how to properly create your components so they are re-usable. Now all of a sudden you found yourself on egghead.io, and some guy is talking about stores, reducer compositions, actions and mapping state to props.

You also realize that while before you were able to do: $(“.my-button”).click(); to get a button to do something; it has now been about 3 hours and your one button doesn’t do anything.

Some Analogies

If you are coming from an MVC (or MVVC) world, you are used to models, views and controllers (duh). However in Redux we are dealing with actions, reducers, stores and components. Trying to “translate” MVC to Redux is tricky but here is how I would do it:

Actions = Controller. Think of your actions as the controller. Whenever you want something to happen in your app (i.e. load some data, change a isLoading flag from true to false…) you will have to dispatch an action. Just like in MVC where you would have to call a controller endpoint.

Reducer = Model. Sort of. Your reducers will be in charge of holding the current state of your application (i.e. user info, information loaded from the api, items you want to display…). It will also be the part that decides what to do when an action is called. While in MVC you might have a model with the method setName(), with Redux you would have a reducer handle an action to set the name in the state.

Stores = ???. The store is Redux specific and doesn’t really have an equivalent in MVC. Not to worry though. This part is taken care off behind the scenes. The store is like a container for the state that aggregates all of the reducers. It has a method to the get the current state, and exposes ways to subscribe to the state changes (using the “connect()” method). This is what will allow you to call actions and pass them in as props to your components.

Components = Views. Components are kind of like your smart views. They display the information that they get from the state. I recommend splitting up your components into two parts. One just for the presentational part (dumb components) and one to handle all of the actions and state changes (smart components).

pssst I tweet about code stuff all the time. If you have questions about how to level up your dev skills give me a follow @mlevkov

Moving From MVC Thinking to Redux Thinking

As you can see (and know from experience) in the diagram above data can flow two ways. You press a button in your view, it sends a message to the controller and that updates the model. The model changes some value, returns the value to the controller, and the controller refreshes the view. Easy peezy!

With Redux things work a little differently. Let’s say you have a component and you want to do something when a button gets pressed. Where do you start? Here is how I go about it.

Define your Action
Define your Reducer
Define the Actions as a Prop in your Component
Wire it up in your View

Here is a simple code example to explain these concepts. In this example I will show how to edit a text input and when a user presses a button it will call an action to save it.

First let’s start with the Action file.

Now onto our Reducer. Basically, the reducer has to handle the actions that come in.

Notice how the constants.MODIFY_NAME and constants.SAVE_NAME are exactly what is being returned by our actions in the type field. That is how you let the reducer know what action is happening.

Now to define our “smart” component. Really all this means is this is the component that will define the call to the actions.

Now for the easiest part. You create your presentational component that the user will interact with (the V in MVC).

And that’s it! You still have to do some basic boilerplate setup stuff, but I hope this clears up how to think in redux.
This was something that tripped me up for a little while (i.e. what information was being passed where and how…) so I’m hoping to save you guys some time and heartache.

If you want to level up your coding skills, I’m putting together a playbook that includes:

30+ common code smells & how to fix them
15+ design pattern practices & how to apply them
20+ common JS bugs & how to prevent them

Get early access to the Javascript playbook.

The Holy Trinity of Functional Programming: Map, Filter and Reduce

Mikhail Levkovsky — Sat, 17 Aug 2019 21:36:20 +0000

You've watched the Youtube videos, you've done the tutorials on Pluralsight and you consider yourself a Javascript expert.

However, now you want to hang with all of the cool kids and talk about functional programming. For loops are for suckers (well not really), higher order functions are all the rage and you want to understand what this means. Well the very first step is understanding the 3 most popular methods which are: Map, Filter and Reduce.

It's important to understand how and when to use these methods, but more importantly, you also need to know when to avoid them.

To setup some context, let's pretend we have an application that saves basic user information. Let's assume our User entity has the following properties: id, firstName, lastName, date of birth, email, an avatar url, a username and a flag to tell us if they are active or not.

User.ts

If the annotations are not familiar don't worry about it. It's not important for the example and is just some TypeORM specific annotations.

To explore the concepts of map, filter and reduce, we will create a class with the following methods:

1. standardizeAvatars 👉 Accepts an array of users, and adds a base url to all of the avatar urls
2. getActiveUsers 👉 Accepts an array of users, and returns only the active ones.
3. getAllAges 👉 Accepts an array of users, and gets the total age of everyone in the array.

pssst I tweet about code stuff all the time. If you have questions about how to level up your dev skills give me a follow @mlevkov

Map 🗺

The .map function goes through every single element of an array and applies a passed in function to each element. There is one VERY VERY important point to pay attention to that's not talked about is that the .map function goes through EVERY 👏 SINGLE 👏 ELEMENT 👏 and returns a brand new array with the modified values.

That means you can't break out of the loop AND you will duplicate every single element of the array. If you have a huge collection that takes up a lot of memory, maybe using a good old fashion for loop is better.

Here is an example of how to convert a for loop to .map.

Filter 🥅

The .filter function goes through every single element of an array and checks if that element returns true or false when passed into the passed in function. If it returns true, we keep that element, otherwise we don't. Phew that's a mouthful. Don't worry there's an example below.

Just like .map, the .filter function goes through EVERY 👏 SINGLE 👏 ELEMENT 👏 and returns a new array with just the elements that didn't get filtered out. So while your collection might shrink in size (or might not), you will still go through every single element without the option to break or continue. If you are doing some heavy computation then on every element that you want to keep, then consider using a for loop.

Here is an example of how to convert use .filter and the same example with a for loop.

Reduce 👨‍👦

The .reduce function will also go through every single element of an array BUT in this case it will not return you another collection, but a single element. In fact, you can say it "reduces" your collection to one item.

The .reduce function accepts a custom function that you make and a placeholder value that keeps track of the operations. This will guarantee that your collection will shrink in size.

There you have it, how to use the holy trinity of functional programming.

If you want to level up your coding skills, I'm putting together a playbook that includes:

30+ common code smells & how to fix them
15+ design pattern practices & how to apply them
20+ common JS bugs & how to prevent them

Get early access to the Javascript playbook.

5 easy wins to refactor even the worst legacy code

Mikhail Levkovsky — Sat, 10 Aug 2019 20:10:32 +0000

So you just joined a new company, you're excited to learn the newest technology and work on some super cool new projects and then BAM, you have to first learn and navigate the legacy system.

All of a sudden the excitement drains from your body as you're navigating helper file after helper file, unable to make heads or tails of the code base.

In this post I will go over 5 VERY common code smells and how to fix them. If you think something is missing, please check out my previous post, 5 easy wins to refactor even the ugliest code.

1) Conditionals should each get their own line

Generally speaking your code will be a lot easier to read if each statement has its own line. The exception to the rule is to combine the else (or else/if) with the ending of the previous if. However, if you are writing a new if statement, it’s important to put it on a new line. This will prevent any future errors, as it may not be obvious that the two if statements are not logically connected.

2) Properly annotate your optional parameters

Optional parameters can be found in most programming language. Typescript uses the '?', Java uses the 'Optional' type, in PHP you can just assign a default value to a method parameter. In Typescript/Javascript, just like keeping the default clause last in a switch statement, it’s important to follow convention to ease development. When it comes to optional parameters, it’s preferable to use the ‘?’ over the undefined definition.

pssst I tweet about code stuff all the time. If you have questions about how to level up your dev skills give me a follow @mlevkov

3) Watch out for “Dead Stores”

A dead store is when you assign a value to a variable but is then re-assigned without actually using the original value. Calculating or setting a value, without actually using it is at best a waste of resources, and at worst a bug in our code. For the following examples, let's assume we have an array of music tracks and we want to calculate the total runtime of all the songs.
A little added bonus in the following example, is the use of the reduce function to get our value.

4) Don’t Invert Your Booleans

One thing to keep in mind as you are developing, is that you are coding for humans, and not for the compilers. It’s better to keep things as simple and as humanly readable as possible. It’s way too complicated to read when you invert the result of a boolean expression, just use the opposite comparison instead.

5) Use Templates. Don't concatenate!

When concatenating strings you should always stick to string templates instead of the concatenation operator. This will make your life much easier as it allows for multiline strings, reduces any errors if your strings have quotes and is generally a lot easier to read. Here is how it would look like when we try to create a TypeORM connection string without string templates and with.

There you have it, 5 more easy tips that you can apply to almost any codebase.

If you want to level up your coding skills, I'm putting together a playbook that includes:

30+ common code smells & how to fix them
15+ design pattern practices & how to apply them
20+ common JS bugs & how to prevent them

Get early access to the Javascript playbook.

5 easy wins to refactor even the ugliest code

Mikhail Levkovsky — Sat, 03 Aug 2019 19:43:15 +0000

Writing clean code can be a challenge when you start on a new project. Trying to clean up code in an already existing application without breaking anything is similar to this:

Heavenly @EVO 🍑

@heavenlycontrol

If you pointed a gun to my head and told me to finish this level i would tell you to pull the trigger

02:10 AM - 16 Jul 2019

55961 164660

I have been a technical lead for a few years and during that time I have seen my fair share of spaghetti code that I had to maintain, or worst extend. Through many painstakingly frustrating hours, and a dozen rubber ducks or so I have developed a few tips and tricks to help refactor even the ugliest code bases.

I put together a list of 5 quick wins that you can either apply to any code base or keep in mind if you're starting a new project.

Each win will start with a bad code sample followed by a good one with an explanation of what changed.

1) No Invariant Methods

A method can be considered pretty much useless if it always returns the exact same thing no matter what is passed in.
As you can see in the example invariant-method-bad.ts, getName will always return the exact same "NO NAME FOUND" message.
We fix this in the invariant-method-good.ts method by simply returning the result that we intended to from the get go.

2) No magic numbers or strings

Magic numbers and strings are hardcoded values that you can find sprinkled throughout your code. If not done carefully you will end up repeating the exact same values across your entire code base, which will make changing your code, debugging and testing it a nightmare.
As you can see below in magic-strings-bad.ts we have a hardcoded string in our method. In the file right below it, magic-strings-good.ts, we fixed this issue by refactoring it to a private read only class variable.

A good question to ask regarding magic numbers and strings, is "Where should I put them?". Here is how I decide where to put them:

Is the value only in one file? 👉 a constant in the top of the file
Is the value used across multiple files? 👉 a specific enum class that groups the constants logically
Is the value used when the application boots (e.g. an api url, a timeout threshold…) 👉 a properties file

pssst I tweet about code stuff all the time. If you have questions about how to level up your dev skills give me a follow @mlevkov

3) Keep the default clause last

A switch statement can contain a default clause to handle unexpected value. Considering you are most likely working collaboratively on a code base, it's important to follow conventions to ease communication.
Considering the example below, just moving the default clause all the way to the bottom will already save a lot of frustration for your peers.

4) Clean up your redundant variables

Keep an eye out when you don't need to instantiate a variable at all. Redundant variables take up memory, clutter up your code, make it harder to debug and add new features. Try to keep your code as tidy as possible. In the examples below, it's painfully obvious we don't need to create an instance of a BackgroundImage each time, and can just assign the value for each case.

5) Forget the else, return if you can

An important concept in keeping code clean is cyclomatic complexity. Cyclomatic complexity is basically how many loops, conditionals or function calls do you have nested in our code. Really high cyclomatic complexity makes code nearly impossible to wrap your head around. You will definitely need a dozen rubber ducks if it gets out of control.
Let's simplify the example from above by going from a switch statement to a tidy series of ifs.

This last example keeps the flow of logic dead simple. There is no alternative flows that you have to map out, everything is very straight forward and becomes much easier to digest.

There you have it, 5 easy tips that you can apply to almost any codebase.

If you want to level up your coding skills, I'm putting together a playbook that includes:

30+ common code smells & how to fix them
15+ design pattern practices & how to apply them
20+ common JS bugs & how to prevent them

Get early access to the Javascript playbook.