“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.
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.
Sometimes DRY and KISS principles seem mutually exclusive. In some cases it is difficult to find the “golden mean”.
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 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.