Software engineering is not only about coding, it is also the ability to solve problems effectively and as efficiently as possible. Application development is an art that requires from an engineer both knowledge of algorithms and knowledge of unit tests, as well as proven principles developed over many years. What rules should a good software engineer know and use?
Clear and simple systems - Keep It Simple Stupid
The "Keep It Simple Stupid" or simply KISS principle was developed by the US NAVY in 1960. According to their assumptions resulting from many years of observation and active work in the field of software engineering, systems work best when they are simple and clear. Difficulties appear when software is more complex and its operation requires more expertise. Moreover, in complex programs there is a higher risk of errors which results from the existence of more elements, often unnecessary and unused. KISS means first of all clean code which is less prone to any errors. It is also easier to maintain and debug.
Uniqueness, that is DRY
"Every piece of knowledge must have a single, unambiguous, authoritative representation in the system" - so reads the book "The Pragmatic Programmer" by Andy Hunt and Dave Thomas. We divide data into parts, each of which should have one source of right and one reference point. This is important so that a change in its area does not force a logical change in the elements that are associated with it. All occurrences of data refer to the same location. The code requires a change to each occurrence every time a single occurrence in the source code is changed. If the code does not follow this rule, we call it DRY. In that case, it needs to be written several times, which translates into wasted time.
Only what is needed
Another principle that every software engineer should know is YAGNI which comes from the Extreme Programming (XP) methodology and was defined by XP co-founder Ron Jeffries. He talked about always impressing the features that are actually needed, not the features that we anticipate might be needed. Engineers tend to build applications with features with potential needs. In some cases, this may turn out to be just an unnecessary extension of the application. However, there are cases where it is worth leaving yourself an "open door". An example is LinkedIn, where you cannot delete comments, and this would be a useful feature for users.
The principle of reversed dependence
This is a principle that first appeared in the article "Design Principles and Design Patterns" by Robert C. Martin in 2000. We learn from it that high level modules should not depend on low level modules. The dependency between them must not be concrete, but abstract. Each class, function and element is assigned a separate responsibility. It is not a best practice to assign multiple responsibilities to one function. This makes the code clearer and it is easier to troubleshoot problems that arise in the code area.
In the same article, the open-closed principle is covered. It refers to being open to extensions and development, while being closed to all modifications and changes. In the case of existing code, you should strive not to make any more unnecessary changes, because the consequence may be the need to change the entire code. Sometimes, however, it is necessary to refactor the code. If it is to improve performance, then the modification should be made. There is always an exception to the existing rule. Programmers should remember not only these key 5 principles of software engineering. A good programmer constantly develops, learns new design methods and technologies, but also does not limit himself to the already proven and valid for many years principles.