Defining your project's start
The best architecture is suitable for me and my project?
Defining your future
When starting a project we should take into consideration several factors before determining an architecture, standard or rite for our project.
Everything we take as true at this moment will impact the future of the project and the team in question, and this is a serious subject that can cost the company time and money, and cost the team a feeling of working on a legacy project that is not well done, which leads to lack of motivation and other problems for example.
At various times we see people commenting on the best standards on the market, the newer technologies ... among others. We should look at all this with an opportunity and absorb their knowledge, but before we really use them we need to know our current and future ( estimated ) challenges of the project / know our team.
Because to propose a solution before,we need to know the problem.
Defining your path
In many projects we ended up having solutions called overkill, solve the problem but are unnecessary to the point of ending up disturbing more than helping. These same solutions can also be called by the book, when we see a concept example Clean Architecture, and we decided to implement it faithfully how was coined by Uncle Bob, but in majorities we really need all the concepts in their smallest details?
Does something simpler do not solve our current problem, but enables us to come back to that point and increase the implementation in a simple way ...
But independently regardless of the context or challenge we need to solve, using certain devices or solutions will always be welcome, example programming with interfaces and not with concrete classes, following the Clean Architecture.
Always try to follow Clean Architecture and the concepts of S.O.L.I.D, which have been shown to be of great importance in a project that has a future in front, but does not hurt to adapt them according to their needs, provided that their solution delivered the same values proposed by both concepts.
Based on my experience, if you build an architecture / propose a solution that is scalable , of easy maintenance and testable , no matter the type of architecture you are using or the Patterns, if your solution obeys these three pillars you will be able to modify and guide it to meet all the future challenges your project / team will have.
Perpetuating success
Guidelines
Something very important to achieve this is documentation / guidelines. It is very important to have a guide to your project, rites, patterns ... because they serve as a first level validation for new members and even old, because something that is not in practice ends up falling into oblivion.
It is of great importance that the whole team participates in the definition meetings, because each person has a different point of view and experiences, the important thing is to find the middle ground that works for the team and the project.
Validations
A second level validation would be static code validations with lints, so that if any developer tries to push something out of standard, it is already blocked in project compilation time.
There are several possible validations, and if ready solutions do not meet all your needs, you can always create custom lint rules.
Continues Integration
The third validation would be a CI, where we will run our validations from lint again, ensuring that nothing has passed, and also where we will run our test suite (unit, ui, integration ...), ensuring that nothing that existed was broken, and what was introduced is working correctly.
This is a very important moment in the software development process, as this is where all team members / outside the team have the opportunity to review the code of one of the others through the Pull Requests.
A pull request is usually where things are born and die, this is where there is the promotion of ideas, opinions, discussions. Use this space to teach others that there is a better way to implement x thing, warn that he forgot something, pointing out a mistake, giving positive or negative feedback by the solution ...