4 Basic Principles of Software Engineering
Software engineering is a complex process, the results of which depend on several variables that are not always determined by the developers working on a specific project.
However, every developer can enhance the quality of his/her code by following four of the basic principles of successful software engineering, which also come in the form of easy-to-remember acronyms!
KISS (Keep It Simple, Stupid!)
That just may be the engineer’s ultimate motto. Engineers tend to build complex systems which cause problems when it comes to their debugging and maintenance. That is why simplicity is the way to go! Whether it is applied on your code or your problem-solving process, keep in mind that keeping it simple is not as easy as it sounds, but it can prove much more effective than complicated structures.
DRY (Don’t Repeat Yourself)
An effective code can be highly reusable and that’s is a good thing, but it doesn’t mean that this piece of code should be repeated in various places within a program. Instead of repeating yourself and your code, see if there is a way to combine all snippets into a single task, thus minimizing the time of efforts you will spend if it is necessary to make any corrections in the future.
YAGNI (You Aren’t Gonna Need It)
A frequent temptation for developers is the urge to take any future eventuality into account and proceed to write code that will solve said eventualities. However, hands-on experience has proven that this proactive way of working is a waste of effort. So, focus on building the code that you need at the moment!
S.O.L.I.D.
S.O.L.I.D. is an acronym that contains five design principles in object-oriented computer programming:
S stands for the Single Responsibility Principle: every module or class should have only a single responsibility (i.e. only changes to one part of the software’s specification should be able to affect the specification of the class).
O stands for the Open/Closed Principle: software entities should be open for extension but closed for modification.
L stands for the Liskov Substitution Principle: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
I stands for Interface Segregation Principle: many client-specific interfaces are better than one general-purpose interface.
D stands for Dependency Inversion Principle: one should depend upon abstractions, [not] concretions.
