Basic Software Architecture Principles (except SOLID)

#architecture #design #programming #refactorit

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?

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

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:

 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

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!

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.

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.

Top comments (3)

𒎏Wii 🏳️‍⚧️ • Nov 5 '21

To be honest, I actually make WET my philosophy: Write Everything Twice (Thrice, to be precise)

That is, I will copy-paste a bit of code exactly once; the third time I need it, that's the right moment to extract it.

The reason for this is a mix of a "just get it to work" mentality and being careful about adding abstractions too early.

Most experienced developers will probably remember a few instances where they thought they understood a problem and knew what to abstract, only to find out that they put a bit too much of the surrounding logic into the abstraction. When this happens, you either have to add ugly hacks to keep the interface intact, or refactor the abstraction and put some of its code back into the calling code.

The third time one needs a repeated chunk of code seems like a good trade-off to me: you've only copied it around once, and you've probably understood enough of what makes the similarity that you can come up with a good abstraction.