Basic Software Architecture Principles (except SOLID)
Tags: architecture, design, programming, refactorit
Published: 2021-11-05 06:28:14

![Architecture Principles](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ys3786b0yu10c1at105y.png)
## Introduction
As programmers we always try to create the BEST CODE IN THE WORLD. But we sometimes start to feel and think things like "Is my code to simple?" "Will it function well?" "Is my code to bulky?" and other nonsense. Well here are some basic principles to follow if you want to become a better and more productive programmer

## YAGNI (You ain't gonna need it)
As developers we are always excited to use and integrate the new technologies that come around: React, Node, Flutter, Docker, Kubernetes. But before implementing this new stuff, stop an think "Do I REALLY need this?" 90% of the time you will say "Yes, of course it's just what my application needs!", but later on in your project you will notice that your application will start to run slow, need a lot of memory and disk space, and will actually slow your coding process a lot! So, just because Facebook is starting to use AWS for their projects, don't think you do! Keep your project as simple as possible! Which brings me to another principle

## KISS (Keep it stupid simple)
This happens a lot in modern programming. People start using unnecessary operations or methods to "optimize" their code for example do you know what this is?
```javascript
let a = 5;
let b = 4;
//Wait for it...
let c = b < a ? 10 : 4
```
If you don't know what this is, it's a conditional way of writing the following
```javascript
let a = 5;
let b = 4;
let c;
if(b < a){
   c = 10
}
else{
   c = 4
}
```
They both return 4, but a simple junior programmer won't know or will get confused when seeing things like that. In principle, just believe everyone your working with or for, is a beginner, so don't add fancy stuff like this so that your ·"code looks pretty and organized." The compiler is not gonna applaud to you if you use ternary operators, both solutions are fine, but KISS, and let everyone know your code.

## DRY (Don't repeat yourself)
I can explain this better with an example:

This is a file inside one of my projects
`add.js`:

```javascript
 let bmObj = bmconfig;
        bmObj.push(bmTempObj);

        fs.writeFileSync(
            require.main.path + '/bmconfig.json',
            JSON.stringify(bmObj, null, 2),
            (err) => {
                if (err) throw err;
            }
        );
```
And lines after I started using this same structure of code inside a different file.
`lib.js`
```javascript
if (!lib && !version) {
        bmObj = [];
        fs.writeFileSync(
            require.main.path +'/bmconfig.json',
            JSON.stringify(bmObj, null, 2),
            (err) => {
                if (err) {
                    console.error(chalk.redBright.bold("Couldn't write file"));
                    return -1;
                }
            }
        );
        return 0;
    }
```
As you may clearly see the same functionality is been repeated a lot!

```javascript
fs.writeFileSync(
            require.main.path +'/bmconfig.json',
            JSON.stringify(bmObj, null, 2),
            (err) => {
                if (err) {
                    throw err;
                }
            }
        );
```
How do you solve this? Simple! Just create a function that writes a specific file with what you want inside it.
```javascript
function writeToBmConfig(bmObj) {
    fs.writeFileSync(
        require.main.path + '/bmconfig.json',
        JSON.stringify(bmObj, null, 2),
        (err) => {
            if (err) {
                return -1;
            }
        }
    );
    return 0;
}
```
And just include this function and replace the code you had in your other files! This now means you only write your code once. And adds more functionality to your application!

## WET (Write Everything Twice)
This one is basically the opposite of DRY. When is it useful? I honestly think when your starting to write your first lines of code. During these stages don't try to think about the DRY principle. Code as your heart desires and later you will notice functionalities inside programs that can actually just can simply function as a method! So yeah if you're starting a project, always keep in mind after taking a break "How should I make my code DRY?"

## Conclusion
Try to focus on this principles when refactoring code or when developing new projects. Sometimes when starting a project we kind of miss this principles! But don't worry, they aren't strict rules for development, their just recommendations when writing code.