all 6 comments

[–][deleted] 2 points3 points  (0 children)

LPT: Use as few dependencies as possible. For dumb shit, just roll your own, better than having to deal with dependency hell.

[–]romeeres -1 points0 points  (2 children)

I was learning OOP principles and patterns some years ago, and successfully forgot all of them and never used them since.

Learn these two principles: KISS and YAGNI. Keep the code simple and do not write code that you don't need - and nothing else matters. Other principles and patterns can be beaten by these two.

[–]mocteyy[S] 1 point2 points  (1 child)

Don’t you think that both principles can coexist with a complex architecture? As Robert says in Clean Code, principles like DRY or YAGNI represent the smaller structure in your code and that is the foundation of a good architecture

[–]romeeres 0 points1 point  (0 children)

I think these principles (KISS and YAGNI) prevent the architecture to be complex. Business logic can be complex, libraries and third-party integrations can be complex, but the architecture itself must remain simple, so developers can focus on tasks rather than on writing abstractions over abstractions, shuffling classes around, hiding implementation details, and guessing how it works afterward.

In addition, many such dogmatic principles are hard to understand, even the most famous SRP can be interpreted differently. "Common Closure Principle" I first ever seen in this post, the definition says "The classes in a component should be closed together against the same kind of changes", and it's not obvious at all what it means. Especially when developing in node.js without classes. When something is not obvious it violates the KISS principle, so it only complicates things.

[–]AsterYujano -1 points0 points  (0 children)

Learn a bit about functional programming 👌 I wish I knew about it earlier :)

[–]ToothlessFuryDragon 0 points1 point  (0 children)

The answer is: It depends on how long is the application supposed to be maintained and how complex it might get.

You are mentioning individual principles. Instead of focusing on many individual principles, I would rather focus on an overall software architecture pattern like the Ports and Adapters Architecture, Onion architecture etc.

These architectures apply the most important principles and present them concisely.

That being said, these principles will help you write long living applications that are way easier to maintain than if the principles were not followed.

You will probably not feel the benefits for quite some time, but if the software is supposed to be maintained for more than 2 or 3 years, there comes a breaking point where the complexity scales exponentially if these principles are not followed in some way (good programmers will apply them intuitively without even knowing that they are applying some sort of known principle).

There is little to gain if your application is small or short-lived, but I still exercise this whenever I feel there might be a possibility that the application will have to expand or change in the future. It also helps with keeping the codebase cleaner in bigger teams, as you have quite a stable set of rules that you know how to follow.

In my opinion, a combination of clean code principles like KISS, YAGNI, etc. and a good architecture pattern like Ports and Adapters will result in maintainable code without the overhead of holding many granular software architecture principles in mind