Bonjour (ou le soir ou le matin, selon la date de publication de cet article).
Je veux parler de la partie élite de la programmation et transmettre, en général, une idée évidente aux débutants en développement back-end (et pas seulement), tout en utilisant une tentative de commencer à écrire dans Habré.
Alors
Tout programmeur avec au moins un peu de bon goût, qui a commencé à programmer tout seul, après avoir compris les bases du langage et écrit les premiers projets, ne se demandera pas «comment faire quelque chose», mais «comment faire quelque chose de bien» et «quelles sont les normes beauté. "
Ces vraies questions, bien sûr, le mèneront tôt ou tard aux noms obscurs «Abstract Factory», «Singleton», «Mediator» et aux abréviations tout aussi compréhensibles SOLID, GRASP.
Veuillez noter que je n'ai pas cité l'exemple de POO, MVC, ORM - ce sont des concepts avec une signification et une portée très spécifiques, avec un niveau d'abstraction minimum.
OOP dit: "Mec, j'ai trouvé un moyen clair et compréhensible de présenter des programmes."
MVC dit: "mec, il vaudrait mieux que vous divisiez le code, et les règles de séparation sont sous le coup."
ORM dit: "pss, mec, je viens de trouver un moyen de réconcilier deux idéologies différentes - OOP et DB."
Tout est clair ici.
Je parle de choses qui impliquent un niveau d'abstraction maximum. Un exemple:
"Médiateur":
les gens, si vous avez beaucoup d'objets différents, faites-en un central, connectez-y tout le reste.
Le programmeur aura juste l'air étrange dans sa direction, s'il est sociable, il dira «merci, casquette!», Et pour les yeux il n'appellera rien de plus que «preuve du capitaine».
Il en va de même pour les autres modèles:
"Usine":
les gens, saviez-vous que vous pouvez construire des objets en utilisant une autre classe?
"Mappeur de données":
pourquoi n'utilisez-vous pas une couche supplémentaire d'abstraction pour enregistrer les données?
"Observateur":
mec, mais obtenons des interfaces?
"Stratégie":
Savez-vous ce qu'est le polymorphisme?
Et surtout SOLIDE:
S (responsabilité unique):
un module ne doit effectuer qu'une seule tâche, ne l'oubliez pas!
I (ségrégation d'interface):
utilisez différentes interfaces pour différentes opérations!
Eh bien et ainsi de suite.
Je mène au fait que le principal domaine d'application des modèles n'est pas du tout l'habitude d'un bon code. Des modèles sont nécessaires pour discuter d'un programme déjà écrit par quelqu'un, pour formaliser un bon code. Pour que vous puissiez dire («à quoi sert cette classe?» - «ah, cela fait partie de l'intermédiaire»). Mais pas pour vérifier ses écrits avec les schémas uml de l'attaque convulsive "aah, quel schéma appliquer dans ce cas?".
Un programmeur qui maîtrise un certain type de concept (par exemple, de ce qui précède) écrira lui-même du code en utilisant les meilleures pratiques, même s'il n'a pas entendu un mot à leur sujet. Et ces mêmes bonnes pratiques sont nécessaires pour formaliser la relation entre son équipe et son code - et la quintessence ici est, bien sûr, GRASP.
Ce que je voudrais dire aux programmeurs débutants:
- Apprenez des concepts, pas des modèles. Les concepts sont vraiment importants.
- si vous venez soudainement à vos sens que vous ne connaissez pas les modèles, ne paniquez pas. Cela n'aura d'importance que pour le recruteur, mais pas pour votre code et votre bon style.
Ce que je voudrais dire au gourou de Habr:
- Je me trompe peut-être. Sérieusement.
- Je comprends que l'idée est courante. Mais, néanmoins, pour une raison quelconque, je rencontre souvent une approche similaire pour les débutants.
- Sur la base du paragraphe 2, un article similaire a peut-être déjà été écrit avant moi. Je ne sais pas.
Et enfin: l'article, bien sûr, est subjectif, je n'encourage personne (à combattre les usines) à quoi que ce soit. C'est juste mon avis :)
De plus, je ne suis qu'un junior, mais cette approche - prêter trop d'attention aux détails - m'a toujours conduit à un malentendu.
Passez une bonne journée!