Software Development Principles Every Developer Should Know.

Your guide to writing clean code that is right.

Principles are pragmatic guidelines that help with reasoning, decision-making, and execution in any domain. They provide a structured way to think, act, and solve problems effectively. For a software developer, principles ensure that code is scalable, maintainable, and efficient, rather than just “working” in the short term. They help in making trade-offs and deciding what to prioritize when designing systems.

The world of software development is a world that at its foundation is fundamentally stable, composed of rules that have not really changed in years. And yet it’s driven by this massive effort of popularity.

The new thing is not really new, it's the same fashioned differently following the same rules.

Here are some solid principles every software developer should know:

1. The Law Of Demeter: A Design guideline in object oriented programming that promotes encapsulation by stating that methods in an object should only call:
   

   1. Its own methods (methods of the same object).

   2. Methods of objects passed as parameters to the method.

   3. Methods of objects it directly creates (instantiated within the method).

   4. Methods of its direct component objects (its attributes or fields).
      

2. Open-Close Principle: This principle states that software entities(classes, modules, functions) should be open for extension but closed for modification. Such an entity can allow its behavior to be extended without modifying its source code. This principle promotes the concept of polymorphism in OOP.

   
   This means, you should be able to change what a class does without changing its source code. You have the class do what you want it to do by calling  a polymorphic interface. And then you can replace that polymorphic interface with a different one and suddenly the class does something different. If it is possible to change the behavior of something without modifying it, that means the next time you are asked to add a new feature to an existing system,  you should be able to do that without modifying any part of the existing system  but writing nothing by new code. 

We’ll change some parts of the existing system but the goal is to minimize it.

3. Principle of Isolation: This principle as defined by Jessica Kerr which is mostly applied to pure functions, states that the only contact a function has with the outside world is via its arguments. The function does not rely on global variables, shared states or external factors.
   

4. Dependency Inversion Principle: This principle speaks of the avoidance of letting high-level policy(business logic) be polluted by low-level details(state changes, function calls). For example, a state or function call change affects a class. Having the high-level policy to be immune from details. Depend on abstraction. Do not depend on concretions. 

Design is all about dependencies. If you refer to something, you depend on it. When the things you depend on changes, you must change also.

To avoid dependencies, your code should be:

1. Loose coupled (Coupling refers to the degree of interdependence between software modules; a measure of how closely connected two modules are; the strength of the relationship between modules) —-> Dependency Injection

2. Highly cohesive —> A class should all be about the same thing (SRP)

3. Easily composable  —-> 

4. Context independent —->
   

5. Single Point Of Failure: This refers to the failure of a single component leading to the complete breakdown or disruption of the entire system. 

To mitigate SPOFs, redundancy, fault tolerance, and high availability mechanisms are often implemented. These mechanisms involve using backup systems, multiple components, or processes that can take over if one part fails, ensuring the system remains operational even if one element encounters issues.

6. Single Responsibility Principle: A function should do only one thing. And one thing means; A function does one thing if you cannot meaningfully extract  another function from it. But if I break down these massive functions, I'll be drowned in a sea of tiny little functions. No, you’ll not drown because these functions will have names. 

Now you’ll likely have a set of functions that manipulates a set of variables. And in OOP, this is called a class. Every large function is an unidentified class.   

7. The Principle Of Least Astonishment: This principle states that code should behave in a way that minimizes surprises for the user (or developer). An example is a Double Take Code (Code that makes you take a second look in surprise). When your code is surprising, it’s bad.
   

8. Code Rigidity: If you modify something and that breaks something else, the code is bad. Rigidity is when you touch the code and you must now modify massive amounts of other code to come back into consistency with that modification. Bad dependencies, systems that are coupled.