Principles are a kind of rule, belief or idea that provides guidance to your activities as a software developer. There are a number of espoused principles that guide developers in a way that creates clear code and streamlines the iterative development cycles
These principles can be expressed using a number of mnemonics. These are useful tools to help you remember facts or large amount of information. Some of them you may already be quite familiar with.
K.I.S.S (Keep It Simple Simon)
Do what you can to ensure your programming is simple and clear to understand. The code shouldn’t create difficulties when being modified or changed. Some suggest that your methods need to be small, not exceeding 40-50 lines, and each method should solve only one problem. Additionally, if you have a lot of conditions in your project it can help greatly to make sure you’ve broken them down into smaller blocks of codes.
Keeping It Simple will allow you and fellow programmers to identify bugs quickly. It also helps you modify and make further changes to the code. It is one of the most common lean principles in agile software engineering.
Y.A.G.N.I (You Aren’t Going to Need It)
Programmers can fall into a pit of trying to implement all the functionalities at once, from the get-go. In the end, some or most of these functionalities may be redundant or useless. An iterative development process always starts by adding just a few methods to a class. After that, as your project starts taking shape and new demands arise, you can add more functionalities. That way, you’ll achieve a lean development software. This saves time, effort and costs that you would have wasted in trying to understand or debug the code.
Measure Twice and Cut Once
Taking a leaf from building and engineering that adage ‘measure twice and cut once’ means developing a systematic approach to the coding process. Double checking all project requirements ensures you don’t leave out or add too much to your code. Developing blueprints to guide the whole process will promote the writing of high-quality code. Iterative development cycles create a develop-test-develop-test framework which helps to ensure the project runs smoothly and efficiently. This principle provides much more predictable outcomes removing the headaches that come with having to delete or add code to meet requirements.
D.R.Y (Don’t Repeat Yourself)
When writing code, don’t repeat yourself. Avoid copy-pasting your code in different places. Rather than being expedient, this can make future maintenance difficult. Any changes made to the coding will have to be repeated wherever you have repeated that code, which means further necessitate changes in the tests to ensure everything works as it should.
To avoid this, you can extract a common logic into functions, and automate any manual works which will keep your code lean.
Occam’s Razor
This principle was defined by a 14th Century philosopher William Occam. It holds that where you have a group of hypotheses that predict the same thing, always select the one that has the fewest assumptions.
In software development an agile, lean approach holds that you should always start with the most straightforward possible code. Then, carefully add the more complex ones only when they’re necessary. Simple codes allow you to easily envision, develop, test, and correct the product at every step. They also significantly reduce bugs and will enable the program to run faster.
Avoid Premature Optimisation
Optimisation speeds up the development process and helps to reduce the consumption of resources and speed up execution times. However, if this is done too early it can lead to problems. It can lead to a messy, hard to maintain system.
To avoid this, start with the easiest approach, and favour writing simple, clean code. Then in the future, assess the chosen method in terms of resource and time consumption, and then based on this assessment, you can move onto a faster algorithm that consumes fewer resources or efforts.
Least Astonishment
The developed product should behave and work in a way that end-users expect. When the product works in a way that is obvious, predictable and consistent, users feel comfortable and confident. Users will users will shy from using features or structures that astonish, surprise, or confuse them.
The principle of least astonishment holds that it is advisable to design a feature that doesn’t have a high-astonishment factor. In other words, it doesn’t need all the ‘bells and whistles’.
Remember that you are making products for people to use. So, by designing user-friendly features that align with users’ mental models, experience, and expectations will leads to positive outcomes.
Demeter
The law of Demeter, or the ‘principle of least knowledge’ holds that in software development you should make every effort to divide responsibilities between classes and reduce coupling between them. The recommendation is to keep software entities independent of each other. You should work to reduce the communication or coupling between different classes, and put related classes in the same package, module, or directory to achieve cohesion. This allows your application to be more maintainable, understandable, and flexible.
S.O.L.I.D
In object-oriented programming this acronym stands for five key programming and design principles. They are:
- Single Responsibility Principle (SRP) - This principle states that a class should have only one reason to change. In other words, it must have only one responsibility. It is about cohesion. All elements in given class structures or modules should have a functional affinity to one another. By clearly defining your class’s responsibility, you increase its cohesiveness.
- Open/Closed Principle (OCP) - The principle asserts that you should be able to change the behaviour of a class without modifying it. Therefore, you can extend the class’s behaviour through composition, interface, and inheritance.
- Liskov Substitution Principle – Liskov (1998) stated that derived classes should be replaceable by their base class(es). Thus, you need to exercise care when using inheritance in your project works. While inheritance is beneficial, it is advisable to use it contextually and moderately. The principle strives to prevent cases where classes are extended only through common things. You need to consider the pre-conditions and post-conditions of a class before performing inheritance.
- Interface Segregation Principle - ISP prefers many specific interfaces to a general interface. The goal is to have finely grained and client-specific interfaces. You need to enhance cohesion in interfaces and develop lean modules - those with few behaviours. Interfaces that have many behaviours are hard to maintain and evolve. So, where possible they should be avoided.
- Dependency Inversion Principle - This principle hold that programmers should depend on abstractions and not on concrete classes. High-level modules need to be independent of low-level ones, and both should depend on abstractions. Abstractions should be independent of details, and details should depend on abstractions. Why? The answer is that abstractions don’t change a lot. Therefore, it is easy to change the behaviour of your closed or open-source code.
In this section you may have encountered terms and concepts that are foreign and confusing to you. Take heart that as you progress through this module things will become clearer. Take time to seek clarification from your tutors, undertake your own independent research, and discuss things with your classmates.
