Basic Rules for Building Great Software¶

Estimated time to read: 7 minutes

In the world of making software or apps, it's not enough to only know how to write code. Some important rules help guide us when we are coding. These rules help us to make software that works well, is easy to understand, and can be changed without too much trouble. These rules are really important in a style of coding called Agile development, and they help shape the way coding teams work together. This article will discuss these rules and why they're important for making great software.

Learning to write good code means understanding some key rules of software development. These rules give coders a good structure to work within. They help us create code that works, can grow and change over time, and is easy to maintain. This article goes over some of the main rules that guide the Agile style of software development.

But remember, these rules aren't set in stone. They are more like guidelines that can change depending on the project or the team. Every coding team is different, and what works well for one team might not work for another. So, it's important to always think about these rules and adjust them to fit your project's needs.

Following these rules can help create a great working environment. Writing clean and easy-to-understand code is not just a technical goal. It also makes the team work better together, makes work more enjoyable, and helps make the software project successful.

So, if you're learning to code, it's a good idea to learn these rules. Always try to make your code simple and neat, and keep challenging yourself to improve. By doing this, you'll become a better coder and help your team and your projects succeed. These rules will guide you in creating great software and help you make a big impact in the world of coding.

YAGNI: "You Aren't Gonna Need It"¶

One of the key principles in Agile software development is YAGNI, which stands for "You Aren't Gonna Need It." This principle encourages developers to avoid adding functionality or implementing features that are not currently required. The idea behind YAGNI is to prevent unnecessary complexity and overhead in the codebase. By focusing only on the essential requirements, developers can streamline the development process, reduce the chances of introducing bugs, and improve code maintainability. Introduced as part of the Extreme Programming (XP) methodology by Kent Beck in the late 1990s

DRY: "Don't Repeat Yourself"¶

The DRY principle emphasises the importance of code reuse and avoiding redundancy. According to this principle, every knowledge or functionality within a system should have a single, unambiguous representation. Duplicated code increases the chances of introducing bugs and makes maintenance harder. By following the DRY principle, developers can ensure that changes or updates must be made in one place, reducing the risk of inconsistencies and improving code readability. Proposed by Andy Hunt and Dave Thomas in "The Pragmatic Programmer" (1999)

KISS: "Keep It Simple, Stupid"¶

The KISS principle advocates for simplicity in software development. It suggests that developers should strive for simplicity in design and implementation, avoiding unnecessary complexity. Simple code is easier to understand, debug, and maintain. It reduces the cognitive load on developers and makes it easier for new team members to get on board. By keeping things simple, developers can improve code quality, enhance productivity, and reduce the likelihood of introducing bugs. Οriginated in the U.S. Navy in 1960.

SOLID: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion¶

SOLID is an acronym that represents a set of principles for object-oriented design and development. Each letter in the acronym stands for a specific principle:

Single Responsibility Principle (SRP): This principle states that a class or module should have only one reason to change. It promotes the idea that each class or module should have a single responsibility, making them easier to understand, test, and maintain.

Open-Closed Principle (OCP): The OCP states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. By designing efficiently extensible software without modifying existing code, developers can avoid introducing bugs and maintain compatibility with existing systems.

Liskov Substitution Principle (LSP): The LSP states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. This principle promotes the idea of designing classes and interfaces to allow them to be used interchangeably without causing unexpected behaviour or violating the expected contracts.

Interface Segregation Principle (ISP): The ISP emphasises creating small, focused interfaces rather than large, monolithic ones. It suggests that clients should not be forced to depend on interfaces they do not use. By adhering to this principle, developers can achieve better code modularity, reduce coupling, and improve code maintainability.

The dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules. Both should depend on abstractions. This principle encourages loose coupling between modules, making modifying and testing individual components easier.

By following the SOLID principles, developers can create code that is flexible, maintainable, and resilient to changes. Introduced by Robert C. Martin (Uncle Bob) in 2000

Law of Demeter (LoD)¶

The Law of Demeter, also known as the "Principle of Least Knowledge," states that an object should only communicate with its immediate neighbours and not with objects further down the dependency chain. In other words, an object should have limited knowledge about other objects to reduce coupling and promote encapsulation. By adhering to the LoD, developers can create more modular code, more accessible to test and less prone to breaking when changes occur in the system. Formulated at Northeastern University in the 1980s.

Composition Over Inheritance (COI)¶

The principle of Composition Over Inheritance suggests that code reuse should be achieved through composition (building complex objects by combining simpler ones) rather than inheritance. Inheritance can lead to tight coupling, inflexible designs, and a fragile codebase. By favouring composition, developers can create more flexible and maintainable code, as objects can be quickly composed and reused in different contexts.

Principle of Least Astonishment (POLA)¶

The Principle of Least Astonishment, also known as the "Law of Least Surprise," states that software should behave to minimise surprises or unexpected behaviour for users and developers. This principle emphasises the importance of creating intuitive and predictable software interfaces. By adhering to the POLA, developers can create software that is easier to understand, reduces the learning curve, and improves user satisfaction.

Separation of Concerns (SoC)¶

The principle of Separation of Concerns advocates for dividing a software system into distinct modules or components, each responsible for addressing a specific concern. By separating concerns, developers can achieve better code organisation, reduce complexity, and improve code modularity. This principle enables teams to work independently on different parts of a system, making development and maintenance more manageable. Introduced by Edsger W. Dijkstra in 1974.

Fail-fast¶

The fail-fast principle promotes detecting and reporting errors as early as possible in software development. By failing fast, developers can identify issues quickly, preventing them from propagating and causing more significant problems downstream. This principle encourages automated tests, thorough error handling, and continuous integration to catch and address issues promptly.

Conclusion

In conclusion, writing robust and maintainable code goes beyond syntax and algorithms. It requires adopting a set of guiding principles that shape the culture of software development teams. The principles we discussed in this article, including YAGNI, DRY, KISS, SOLID, LoD, COI, POLA, SoC, and fail-fast, provide a foundation for creating efficient, reliable, and easy-to-modify software. By incorporating these principles into their development practices, teams can improve code quality, enhance productivity, and deliver successful software projects. Remember, writing great code is not just about the result; it's about the journey of continuous improvement and learning. So, embrace these principles, iterate on your code, and strive for excellence in every line you write.