¿Cómo puedes evitar el anti-patrón de culto de carga?

It could really be a good start for transitioning to design a good and effective layout for a system using principles but as you grow mature you'll come to know that there isn't a single solution / principle that doesn't have any cons. It's either personal bias or surrounding situations using which the development is driven.

In my experience, copy paste is part of life and need of hour also. However it can turn into nightmare if we don’t follow below religiously: - start any feature development with LLD (use case design, class design & sequence diagram) - API design document - schema design - rigorous code review process. Flowing this practice ensures your developers understand what’s being built, why is it being built, how API would behave, what would be the possible input parameters and expected output. If your team has this clarity before working code, then it doesn’t matter if they copy code from elsewhere or write it all by themselves.

Reading the source and test suites of the libraries you're working with or depend on helps to understand better and lose this naïveté about "magic". Furthermore, you might see patterns and affordances already in place in the library but didn't know about and reimplement, sometimes poorly by lack of better knowledge, on your side.

Copy paste code only to solve specific granular problems at hand. Yes one needs to understand the pattern first , it's pros and cons before using it.

Knowing about design patterns may sometimes be a double-edged sword : If you understand the pattern well, it's uses and drawbacks, then you'll usually know when it is appropriate to use it or a its version. But superficially knowing "about" patterns may lead to the golden hammer problem : if you've only learned about singletons and observers, then you'll tend to use them whether they are needed or not. Sometimes it is better to think about the problem whilst "forgetting" about patterns, and only after you have a clear idea about possible solutions, try to see if there are patterns that can help improve on them.

You don't have to follow design patterns to the letter. Learn where it makes sense and where it doesn't, based on what the business actually needs. For Example, micro services should each have their own data store, right? Well, not exactly. The problem you want to solve is preventing developers from mixing together functionality in different micro-services in a way that circumvents separation of concerns, as well as the possibility of noisy neighbour syndrome. You can still share the same multi tenant data store, as long as you separate data logically, not necessarily physically. So it is totally fine, if all your micro-services all store their data on S3, even though it is technically "sharing a data store".

One thing I've noticed is that on FrontEnd projects with modern stacks, teams often completely overlook CSS or native HTML capabilities. Ignoring its importance and proper use and create something that could be made by a simple HTML form and a few inputs and an event listener. Or complexity of making modules and paints themselves in a corner because they aren't using native DOM events. CSS overlooking is also very costly, bugs where things gets defaced, elements getting hidden under other elements is a symptom of lack of understanding the rendering model.

Sometimes I feel that following design principles would help you think of a refactor which in turn would lead you to the right path of applying a design pattern. Readability, testability, maintainability will push you to refactor. Uts will cover your back and give you all the guts to refactor

We always assume "best-practices" will get us the best results. But in actuality, best practices make assumptions about our use case, based on the use cases examined at the time of creating those best practices. For example, the market leader may be product A, and it is always best practice to follow the industry standard. But maybe your use case better fits product B. If you know your product well enough, and understand the tradeoffs, you can make better decisions.

Old architectures can sometimes only take you so far. Maybe you built something on top of a stack that is no longer maintained properly, or maybe it is simply hard to find engineers who know how to use your programming language. I remember 9 years ago when we worked on dismantling a monolith into micro-services, and the huge performance boost that came with it. Don't fear the refactor, embrace it.

Refactoring is a useful strategy for migrating from one architecture to another. But it is important to have the right tools in your belt before you start. Robust unit tests and end-to-end automatic testing of the code you intend to refactor is essential. It gives you the peace of mind in knowing you didn't break anything during the transition.