Software development problems and principles for avoiding them

In software development, there are certain principles that we should follow and strive to apply them in order to write good code and quality software. But, what makes code good or bad? How quality of code impact the speed of development, extensibility of software and customer satisfaction

Symptoms of bad code, according to inventor of SOLID principles, are:

  • Rigidity – If one new small functionality force you to make a chain of changes, then you knew that your code is rigid. That means that your code/classes/modules are incorrectly linked.
  • Fragility – If your code is dependent on the data structure on a bad way, you will have frigid code. You can recognize frigid code when a change on one part of application impact on something that should not be connected with that. You have unexpected consequences. This can really make your client angry and scare him away from the changes as they will doubt the stability and quality of your application.
  • Confusing – code that is hard for understanding and reading. The code should be self-explanatory.
  • Spaghetti code – when code works everything it should, but it has some additional functionality and dependencies that you don`t need. That just makes unnecessary lines, code is harder to read and understand. But when you try to remove it you realize that it is tightly coupled with rest of code that you can`t remove it without consequences and refactoring.
  • Immobility. You can not reuse parts of the code in other projects because of involved risks and high effort.

Some of the most famous principles for clean and quality code are:

  • DRY – don`t repeat yourself (use abstraction instead);
  • KISS – keep it simple, stupid ;
  • The “composition over inheritance” – objects with complex behaviors should do so by containing instances of objects with individual behaviors rather than inheriting a class and adding new behaviors;
  • YAGNI – you are not gonna need it – is the idea that you should never code for functionality that you may need in the future;
  • SOLID – contains five principles;

The SOLID design principles were promoted by Robert C. Martin and are some of the best-known design principles in object-oriented software development. It is an acronym for the following five principles:

SINGLE RESPONSIBILITY PRINCIPLE

A class should have only one reason to change – that prevents rigidity (change of one thing breaks other things). The code should be separated in different classes and modules by factors which can impact on business logic.

OPEN-CLOSED PRINCIPLE

You should be able to extend a class without modifying it. This principle is supported by polymorphism, which allows us to add new features by adding new code without changing the old code (by extending the class or implementing interfaces in different ways).

LISKOV SUBSTITUTION PRINCIPLE

Derived classes must be substitutable for their base classes, without the need for the user to know the difference. There are things that look like they are the same type but they are not really the same, they have one more or less functionality then parent class. If we need to check the type of object, there is a big possibility that we have made some mistakes

INTERFACE SEGREGATION PRINCIPLE

Make fine – grained interfaces with specific methods. More small interfaces are a better solution than one big interface because in that way we achieve decoupling. For example, we can have an interface for a drink, eat, move, sleep methods and we can have different types of organisms, so some of them will implement all interfaces, and some of them just a few.

DEPENDENCY INVERSION PRINCIPLE

It depends on abstraction, not on concretions. High-level modules should not depend on low-level modules. Both high and low-level modules should depend on abstraction. Abstraction should not depend on details.

 

This was an overview of the most popular design principles in software development, and we can conclude that is better to spend more time thinking about software design and architecture rather than fast writing bad code. There are many fields for improving and learning in software development and this is certainly one of them.