Write cleaner code by doing less. The S in SOLID.

There are five principles the help you write better code, known as SOLID.

In this video, we look at the first of these principles, known as the Single Responsibility Principle, which dictates that modules should only be responsible for one thing and to do that one thing well.

#coding #solid #architecture

My socials:

Please consider supporting me as well!

[egor.okhterov]

One thing I would add is that what we should apply is called "need based approach" (YAGNI). Every code that you write is good enough as long as it is correct. The primary goal for you as you start implementing the feature is to produce a working solution with as little code as possible. In the beginning you don't even know what logic and classes will survive and the changes you make in the beginning are quite drastic: functions and files appear and disappear out of existence. Eventually the code base for the feature stabilizes. After a month you notice that it became hard to make a certain change and that becomes your "need". Now you try to understand how code should look like in order to facilitate the change that you want to introduce (not more than that) and do a preparation refactoring. Once you have prepared the code base using some of the software engineering principles and patterns as your guide, you introduce the feature change that fits in nicely and naturally.

Don't do refactoring for the sake of refactoring. Apply need based approach. Less is more.

[coderized]

Nice video! It's a hard topic to explain to people at the small scale because they see it as "excessive", but the real power comes as the project grows. Without it, it would be like trying to run a successful business where all the employees share all responsibilities without any clearly defined roles (HR, Coding, Marketing, Accounts, Sales, etc) - maybe you can get away with that in a Startup but at the Enterprise level it would soon implode.

[TheOnlyEpsilonAlpha]

I've build a project exactly like that without known that principal. Because it simply make sense to do it like that

[VeryCreative]

I was rewatching this video a few days ago and I just want to say: I would love if you could explain the rest of SOLID to us. And maybe even other programming paradigms such as the 12 factor principle, or different design patterns. Sure: most things are known at this point already. But man you just have such a good way of explaining things.

[parlor]

I think you overlooked the most important problem here which is that the code is written in GO. This breaks the D in SOLID which stands for "Please don't write GO code" and the O too which stands for "Oh no"

[asdqwe]

I dont know, people tend to spend tones of time adding abstractions around a database that they are never going to replace anyway. To me, scattering logic in different files doesnt make code that much easier to read.

[iamrafiqulislam]

As usual, very comprehensive Nine and Half minutes. Thank you! Again another request for a topic, please - I try to grasp Hexagonal Arch (Ports and Adapter), but I mess up with true implementation and I am bit lazy to write testcases :(. I am trying to learn and understand Rust with you (I am still at the first step 'a' on Rust), so Hexagonal Arch implementation both in Go and Rust would be a nice help. And again, thanks in advace and sorry to request for videos on each video!

[wlockuz]

Awesome video! kudos for acknowledging that SOLID is not exclusive to OOP, Its just good practice in general.

Hope you also cover the other letters as well!

[Lorkin]

1 million subs within 1 year, if you keep this up. Another excellent video!

This channel is a backend goldmine

[wWvwvV]

I do it exactly as described here, except I also put the DB-funtionality in a separate package. The data/domain-package, in this case the user-package, should have only functions to operate on itself, like searching for a user in a list. No other dependencies should be allowed, except necessary data-processing-libs.
I name related packages similar to put them next to each other in between other packages. As the code base gets bigger and more complex, I now think a better approach is to group related packages intuitively under the domain-package, when there is more than one domain-package in the module. But don't "abstract" names of sub-packages. Don't call a sub-package "repo". There must be a "user"- and a "user_repo"-Package (I would label it "userrepo" or "userdb").

[KingJellyfishII]

In my opinion, SRP shouldn't be used universally. for example, imagine some hypothetical code for the game Minecraft: you need to represent a lot of different blocks with different behaviours represented by classes. The SRP would dictate that you have a module for rendering, a module for (de)serialisation etc. The alternative is to have each class be responsible for its own rendering, (de) serialisation, updating, etc. If you need to add a new block, it's as simple as creating a new class and implementing the required methods, whereas the more abstracted code would require you to modify many modules to add the functionality in different places.

[menahem-mendelg]

I haven’t realized the srp till I started to write services using kratos framework. Now I don’t need to remember what each function is doing and can write tests more easily without hours of debugging. Thank you for the video

[ebukaume]

Nice one as always. But how do we really define "one thing"? Eg: should harsher be checking if password is correct or should it do just hashing and do it well? I think these boundaries are subjective

[cherkim]

Wow! You are very knowledgeable! Great video. Where did you learn all of this? Best coding YouTuber by far!

[arun_kannan]

Would love it if you can cover other 4 in SOLID as well

[saniancreations]

You just turned a very easy to read easy to understand piece of code into 4 separate harder to read pieces of code spread across multiple files/folders.

One of the structs you create doesn't even have any member variables, meaning that you could just as well have made a stand-alone function to perform that task, because the function you associate with that struct evidently doesn't even need the struct in order to work.

By religiously applying this principle you are actually introducing complexity, not taking it away. This line of thinking is exactly how you end up with codebases made completely unworkable because everything is powered by

[sorvex]

Lol this example was eerily relevant for the project I am sitting and refactoring right now.

[blankRiot]

Really cool video mate, I think my interest in writing clean code is slowly getting ignited again

[typecraft_dev]

this is great. easier to read, easier to test, easier to extend and maintain

[lel]

Great video ! Crystal clear as always. I do find that code modularity and reusability is a big deal and for debugging it really does make a difference.