Software Development Principles

“What's true for love, is true for code. The fundamental things will always apply. “ – Chris Peters

These days software developers must not only understand and apply proper code techniques but also stay competitive by learning and adopting languages and concept that pop up.

“Measure twice – cut once”

Everyone knows that good developers do not “get their hands dirty” immediately after they receive the task. The first thing they do is to start with a good planning. Good planning is based on knowledge and understanding of common problems that the developers hit over time and finding proper solutions. Below you will find some of the most used software development principles.

DRY (Don’t repeat yourself)

In the real world, applications that are a 100% DRY are hard, if not impossible, to achieve. However, applications that do not follow the principle to an unacceptable degree are therefore hard to maintain and should be avoided.

KISS (Keep It Simple, Stupid)

Sometimes DRY and KISS principles seem mutually exclusive. In some cases it is difficult to find the “golden mean”.

YAGNI (You Ain’t Gonna Need It)

YAGNI is a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".

Buy, Not Build

Don't invent new solutions to solved problems! Take full advantage of the platform, even if it only solves the 80% of the case.

SOLID principles

SOLID principles are the design principles that enable us to manage with most of the software design problems. Robert C. Martin compiled these principles in the 1990s. These principles provide us ways to move from tightly coupled code and little encapsulation to the desired results of loosely coupled and encapsulated real needs of a business properly. SOLID is an acronym of the following.

S: Single Responsibility Principle (SRP)

A class should have one and only one reason to change, meaning that a class should have only one job.

O: Open closed Principle (OSP)

Objects or entities should be open for extension, but closed for modification.

L: Liskov substitution Principle (LSP)

Every subclass/derived class should be substitutable for their base/parent class.

I: Interface Segregation Principle (ISP)

A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

D: Dependency Inversion Principle (DIP)

Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

Images above are SOLID Motivational Posters, by Derick Bailey, licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Veronica Milcheva

I am a passionate Sitefinity blogger, developer and consultant. In my spare time I enjoy running and listening to music. My personal quote: There's no tough problem, just not enough coffee :)

Sofia, Bulgaria