Subscribe to my email list now at http://jauyeung.net/subscribe/

Follow me on Twitter at https://twitter.com/AuMayeung

Many more articles at https://medium.com/@hohanga

Even more articles at http://thewebdev.info/

Emergent design is a framework for systematic change. It focuses on delivering small pieces of working code with business value. It’s part of agile software development, which is more flexible than traditional software development.

In this article, we’ll look at the four principles of software development with emergent design.

What Are the Four Rules of Emergent Design?

The four rules of emergent design are simple. They’re:

• Running all the tests.
• Removing duplication.
• Expressing the intent of the programmer.
• Minimizing the number of classes and methods.

Running All the Tests

Running tests ensures that our system is still acting as expected after we made changes. The design might have been perfect on paper, but after doing the work, we may find unexpected flaws in the system. So we have to run tests to make sure that our changes are good.

We have to write code that’s easily testable. This means that the code should be loosely coupled so it can be easily tested by unit tests. Loose coupling also means that code can be more easily modified since it doesn’t affect other parts of the code.

We can use dependency inversion tools like dependency injection and abstractions to minimize coupling in JavaScript code.

Writing tests enforce low coupling and high cohesion since writing easily testable code requires code with these two characteristics.

Refactoring

Once we have tests, we can refactor without thinking too much about breaking things since we have tests to make sure that we don’t break anything.

We can apply the principles of good software design like SOLID when we refactor the code.

When we refactor, it’s time to choose better names, write smaller classes and methods, reduce the number of classes and methods, and write more expressive code.

Removing Duplicate Code

Duplicate code should be removed when we refactor code. Less duplicate code means less code to maintain and fewer places that we’ll forget to change.

Duplicate is not just code that is exactly the same. Their implementation can also be duplicated. For example, we can have a size and isEmpty methods for our own data structure.

They’re so similar that we don’t really need both. We can just make isEmpty return size() === 0;.

Code with duplicate implementation can be extracted into a common location. Anything that violates the single responsibility principle has to be extracted into its own class.

For example, let’s say we have a postal rate calculator to calculate international mailing rates as follows:

class PostalRateCalculator {
  calculateUSRates() {

  }

  calculateEURates() {

  }
}

We really don’t need two functions since the only difference between the two methods is the postal rates. Therefore, we can combine them into one method and use the different rates for different countries to calculate the rates as follows:

class PostalRateCalculator {
  calculateRates(country) {
    if (country === 'US') {

    } else if (country === 'UK') {

    }
    //...
  }
}

This way, we don’t have two methods that do similar things cluttering up the code.

Expressive Code

Expressive code means easy to understand code. Our code has to communicate our intentions clearly so that readers won’t misunderstand what we’re trying to do.

We can be expressive by choosing good names for everything.

Also, keeping a standard nomenclature for everything reduces the chance that we’ll be misled when other people read our code.

Well-written unit tests are also expressive. They should tell us a lot about what the program does since we have inputs and outputs all in one place. In addition, each test has its own description to tell us even more information about the part of the system that it’s testing.

Minimal Classes and Methods

If we don’t need the code, then we shouldn’t write it. Useless or duplicate code is just bad.

They clutter up our programs while providing little to no value.

Conclusion

There isn’t a clear cut way to use emergent to write our programs. However, it’s mostly down to refactoring using the clean code principles and then using unit tests to make sure everything still runs correctly.

Also, we have to write tests as if they’re documentation. Just like normal code, they have to be expressive.

Duplicate code or code with similar implementation can probably be merged into one.

The post JavaScript Clean Code: Emergent Design appeared first on The Web Dev.