Top 8 Principles For Junior Software Development
Hello everyone, we want to share a short article on the most famous principles of software development. The article will be useful for novice developers because experienced people are unlikely to find here something new. But newcomers also need to read something.
The principles of software development are a set of specific rules and recommendations that you need to follow when writing the source code of the program if you want to write beautiful, understandable and easily editable code.
That is, there is no magic wand with which you could turn a hash of variables, classes, and methods into an ideal listing, but there are some tips that help the programmer determine whether everything is right. Let’s look at these basic recommendations.
Principle #1 Do not Repeat Yourself (DRY)
A fairly simple, but very useful, principle that says repeating the same code in several places is a very bad idea. This is due primarily to the need for continued maintenance and modification of the code.
If a particular piece of the listing is repeated in several places in the program, then there is a high probability of two deplorable situations:
- If you need to make even the slightest corrections to the source code, you will have to look into all the places where it is used, which will require additional time and effort
- From the first point the second follows, you or another developer can accidentally skip one of the fixes and run into subsequent application errors
In this regard, there is a recommendation, if any code occurs more than twice in the listing, then it must be taken out in a separate method. This is a general recommendation, in fact, you need to think about highlighting the method even if you meet a second time.
Principle #2 Occam’s Razor (OR)
A very common idea that came in programming from philosophy. The principal received its name in honor of the English monk William of Occam. This principle reads: “One should not multiply things without necessity.” In the field of programming, this rule is treated as follows – you do not need to create extra entities without the need for them.
That is, always think about whether you will benefit by selecting an additional class or method. After all, if you single out a single line in a single method, which does not repeat anywhere else, just confuse and complicate your code.
Principle #3 Keep It Simple Stupid (KISS)
A principle similar to the previous one, but having a slightly different meaning. This recommendation says that the code needs to be written simple, without complex designs, since otherwise it can significantly complicate the maintenance and debugging.
In addition, it will be much more difficult for another programmer to understand the intricacies and complex branches of the listing, which will also require additional effort and time. Therefore, always try to use simple and logical constructions without deep nesting, so you simplify the life for yourself and your colleagues.
Principle #4 You Are Not Gonna Need It (YAGNI)
The problem of which many programmers suffer. The desire to develop immediately all the potentially necessary (and sometimes even unnecessary) functionality from the very beginning of the development process. That is when the developer from the very beginning adds all possible methods to the class and implements them, and in the future can even never use them.
Therefore, according to this recommendation, develop only what you need in the first place, and in the future, if necessary, increase the functionality. So you will save the polygamy of forces, time and nerves for debugging code that is not really needed.
Principle #5 Big Design Up Front (BDUF)
This is the opposite of the previous principle, which states that before starting to develop it is necessary to plan and design the entire information system in advance, down to small enough details, and only then to proceed to implementation according to a pre-prepared plan.
- The principle has the right to exist, but recently a lot of his criticism has been encountered. First of all, this is due to the aging of the plan for the time of design and development. In this connection, you still have to make subsequent changes.
But it also has irrefutable advantages, with proper design, you can significantly reduce the costs of further debugging and bug fixes. In addition, such information systems are usually obtained more concisely and architecturally correct.
Principle #6 Avoid Premature Optimization (APO)
Optimization is a very correct and necessary process that allows you to speed up the program, as well as reduce the consumption of system resources. But everything has its time.
- If optimization is carried out in the early stages of development, then it can do more harm than good. This is primarily due to the fact that it takes more time and effort to develop an optimized code. In this case, often enough to first make sure the correctness of the chosen development approach.
Therefore, in the beginning, it is more advantageous to use simple, but not the most optimal solutions. And in the future, evaluating how much this application slows down the application, make a change to a faster or less resource-intensive algorithm. In addition, for the time while you will initially implement the most optimal algorithm, the requirements can change and the code will go to the trash. So do not waste time on premature optimization.
Principle #7 Principle Of Least Astonishment (POLA)
This principle says that your source code should be an intuitive, obvious, and as little surprise to another programmer while reading the listing.
- This means that if the method is called “Make a car” and the result is a motorcycle, it’s a bad idea and bad code. In fact, we now certainly exaggerate, but in any case, your methods should do only what you can understand from their name.
And the names should be the most informative, but concise. You do not need to write a whole sentence in the name, but you do not need to call it a single letter either. Strive to ensure that the code you wrote could be read as a book.
Principle #8 Law of Demeter (LOD)
The main idea of this law is to divide the areas of responsibility between classes and hide the internal structure from the external environment. That is, each class should strive to be maximally independent and detached from other classes, and if necessary, interact only with the necessary other classes of “friends.”
From this law, there are several recommendations:
- Classes must be independent
- You should try to reduce the number of links between different classes
- Classes must be hierarchically
In regard to the last point, you can give an example from life. In order to make the dog run, do not need to go to each of its paws separately. It’s enough to give the command to the dog, and she will do everything herself to come running to you.
By observing this principle, the application becomes more flexible and understandable.
Conclusion
Here we listed the basic principles that should be followed when developing the source code of the software. If you follow them, your code should become more flexible, easily maintained and readable. But remember that everything is good in moderation, and excessive use of these principles can do more harm than good.
