DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 967,611 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
The Unfactoring Guru
The Unfactoring Guru

Posted on

Basic Software Architecture Principles (except SOLID)

Architecture Principles

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
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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;
            }
        );
Enter fullscreen mode Exit fullscreen mode

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;
    }
Enter fullscreen mode Exit fullscreen mode

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;
                }
            }
        );
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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 (2)

Collapse
 
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

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.

Collapse
 
the_unfactoring_guru profile image
The Unfactoring Guru Author

Exactly!!!

πŸŒ™ Dark Mode?!

Turn it on in Settings