Bonjour, je m'appelle Pavel et je suis full-stack chez Mad Devs * applaudissements *.Dans le contexte d'un grand nombre d'articles et de documents sur le fait que
les piles complètes ne sont pas nécessaires ,
les piles complètes n'existent pas ,
les piles complètes sont mauvaises , il y a une opinion sur
les avantages d'une pile complète par rapport à des spécialistes spécialisés et pourquoi
les piles complètes sont nécessaires .
Je voulais laisser une liste de liens vers d'autres articles sur les piles complètes au début de l'article, mais il y en avait trop, donc je suis désolé. Je veux juste dire qu'il y a suffisamment de matière pour expliquer pourquoi une pile complète est bonne et pourquoi une pile complète est mauvaise. Et chacun d'eux est au moins 50% vrai.
Il y a probablement des émotions et des pensées personnelles qui ne prétendent pas être le dernier recours.
Comme je l'ai déjà dit, je m'appelle Pavel, cela fera bientôt 7 ans que je reçois de l'argent pour la programmation. Et pendant toute cette période, je me suis appelé dans le CV, lors des entretiens et dans d'autres endroits:
développeur Backend avec des connaissances et des compétences en Frontend et DevOps . D'une manière ou d'une autre, dans une carrière professionnelle, il a souvent travaillé comme back-end sur des projets, mais il n'a jamais eu peur ni du front ni des ops. Par conséquent, il a fièrement ajouté ces deux domaines à sa description. Certes, avec l'arrivée de Mad Devs et, après avoir travaillé sur l'un des projets avec notre équipe MadOps, j'ai supprimé DevOps de ma description, car maintenant je crois que je ne le comprends pas du tout. Tout en comparaison est connu, comme vous le savez. J'espère un jour travailler avec les mêmes spécialistes front-end qui me "persuaderont" de supprimer le post-script front-end. L'essentiel n'est pas de rencontrer un backender, ce qui vous obligera à supprimer le backend du CV, sinon il ne restera plus rien.
Les arguments les plus fréquents des experts qui écrivent et croient qu'une pile complète est mauvaise sonnent comme ceci:
Aucune immersion dans aucun des domaines ,
vous ne pouvez pas être un développeur senior Fullstack ,
les spécialistes de haut niveau étroits gagnent plus que les piles complètes fortes , etc. Et vous savez, je suis d'accord avec eux.
Au cours des derniers mois, j'ai travaillé sur le projet Peklo Tool, qui utilise Ruby sur le backend, VueJS sur le front et Go pour implémenter un générateur de texte.
Et je ressens les problèmes:
- Je pense que ce code sur Go peut être mieux écrit et fonctionnera plus rapidement ou utilisera moins de ressources système;
- Je pense que ma configuration webpack peut être configurée beaucoup mieux, il y a beaucoup de déchets maintenant;
- Je pense que cette mise en page peut être faite en utilisant des fonctionnalités CSS, SCSS modernes, ou prendre PostCSS ou d'autres extensions;
- Je pense que le code sur les rails peut être optimisé afin que moins de requêtes dans la base de données soient faites, par exemple;
- Je pense que les index doivent être configurés humainement dans la base de données;
- Je pense que ce Dockerfile doit être réécrit afin qu'il y ait moins (ou plus) de couches;
- et ainsi de suite, ainsi de suite, etc.
Je peux tout ressentir. De plus, je veux vraiment tout faire. Et, lorsqu'une minute gratuite apparaît, je résous partiellement au moins un de ces problèmes.
Vous me demandez:
pourquoi n'utilisez-vous pas immédiatement la chose N à cet endroit pour qu'il n'y ait pas de tels problèmes?Et je répondrai:
je ne connais pas la chose N, tellement bon que je peux l'appliquer rapidement dans un projet dans un certain cas. Je prends juste le temps du développement - lisez le problème:
il n'y a pas d'immersion complète .
Et je ne mentirai pas, car le projet sur lequel je travaille a besoin de fonctionnalités. PekloTool est un outil professionnel pour générer des campagnes publicitaires contextuelles. L'outil est jeune, le développement est en cours depuis un peu plus d'un an, mais il est entré en production il y a seulement quelques mois. En conséquence, nous faisons maintenant toutes les fonctionnalités utiles pour un tel produit.
Comment puis-je savoir que des fonctionnalités sont nécessaires et que ces fonctionnalités seront utiles? Très simple
car je suis pile pleine . Je vois tout le projet. Je vois les objectifs du projet, je vois comment il fonctionne, je vois ses montants non seulement techniques, sur lesquels j'ai écrit ci-dessus, mais les montants que les utilisateurs verront.
Et nous arrivons ici au point principal de cet article: je crois qu'une pile complète moderne ne devrait pas être juste un encodeur capable de faire des backends, des front-ends ou autre chose. Fullstack est une personne impliquée dans le développement d'un projet. En plus des compétences backend, frontend, etc. full stack doit avoir une compréhension du domaine du projet, des connaissances UX / UI et même un peu de marketing. Fulstack doit savoir comment le projet remplit sa tâche principale: gagner de l'argent ou sauver le monde. La pile complète doit être sur un pied court avec le «client» du projet. Tout projet a un «client», s'il s'agit d'une entreprise d'impartition, c'est un client, dans une entreprise de produits, c'est une partie prenante ou un produit. Le «client» doit voir dans la pile complète le spécialiste avec lequel vous pouvez consulter sur toutes les questions concernant le projet.
Dans le manuel du nouveau venu Mad Devs (le même document que l'on vous a donné à lire le premier jour de l'entreprise), il y a un article appelé: «Affinité client» (
Eng. - «Proximité client»). J'ai décrit l'essence du terme dans le paragraphe précédent. Une pile complète doit toujours mettre le chapeau d'un client, l'option idéale est lorsque le «client» effectue des tâches de sprint avec une pile complète. Autrement dit, une pile complète comprend l'historique de l'apparence de chaque tâche et ne résout pas seulement les tâches qui lui ont été attribuées. Je crois que si une personne fait simplement des tâches et que son travail s'arrête là, même si elle fait un backend, un frontend, un téléphone portable, etc., ce n'est pas une pile complète. C'est juste un back-end qui peut faire du front-end, ou vice versa.
J'écris donc tout cela, et le lecteur peut avoir deux pensées:
- quelle absurdité . Ici à chacun le sien. Si vous le pensez, vous êtes probablement un spécialiste étroit, alors votre opinion est claire. Mais, si vous êtes full-stack, je vous «rendrai heureux». Vous perdez une énorme couche d'activités utiles qui profiteront à votre projet, et perdez également la possibilité d'acquérir des compétences importantes qui peuvent déterminer le développement de votre carrière;
- Est-ce à cela que devrait ressembler une pile complète sur un propriétaire de produit? Oui tu as raison. À l'exception de quelques points: le produit-oouner est souvent le chef d'équipe de l'ensemble du projet. Je n'attribuerai pas de qualités de leadership à une pile complète. Il s'agit d'autre chose. Eh bien, le produit-oouner devrait être en mesure de considérer le coût de développement d'un projet, une pile complète n'est pas nécessaire pour penser aux finances liées au développement. De son poste, il y a déjà de l'argent pour le développement. Bien sûr, il peut proposer des options pour réduire les coûts de développement, mais uniquement en pourcentage ou en termes qualitatifs, pas en termes quantitatifs. Peut-être quelques instants me manquent certains que le produit devrait pouvoir, mais je peux, je suis pile complète.
Il y a un autre côté de la médaille que je veux décrire. C'est
triste . Le problème avec les piles complètes est qu'elles sont surchargées. C'est évident. En règle générale, nous effectuons des tâches très volumineuses, des fonctionnalités complexes. Nous avons toujours une communication avec le client pour proposer des fonctionnalités et des tâches dont j'ai parlé ci-dessus. De plus, lorsque vous voyez l'ensemble du projet d'un point de vue technique, vous travaillez souvent sur l'infrastructure, l'architecture et d'autres choses. Plus il y a d'informations, plus il y a d'idées et plus il y a d'idées, plus elles ont de chance de se réaliser. En conséquence, vous pensez souvent: peut-être une base de données NoSQL, ou peut-être GraphQL, ou peut-être autre chose. C'est là que l'emploi apparaît par lui-même. Je ne parle pas du fait que je cours immédiatement pour tout transférer dans le GraphQL conditionnel, mais vous acceptez parfois vous-même quelques idées plus petites et les implémentez. Bref, très occupé.
Tu veux quoi? Je voudrais essayer une nouvelle bibliothèque, étudier davantage la configuration Gitlab CI, fumer quelque chose d'intéressant et relativement nouveau pour moi à l'avant, par exemple Logux. Mais il n'y a pas de temps, vous êtes responsable du projet. Je ne dirai pas que cette
tristesse , juste une triste tristesse. En revanche, je reçois un gros buzz: à partir du moment où je vois des critiques positives des utilisateurs; quand ils écrivent joyeusement sur une fonctionnalité à cause de laquelle vous n'avez pas dormi pendant quelques jours; lorsque le nombre d'utilisateurs augmente.
En conclusion, j'exprime l'idée que les spécialistes étroits et larges ont leurs propres avantages pour le projet, leur carrière, leur environnement et leurs inconvénients. À mon avis, je décrirai les avantages et les inconvénients professionnels spécifiques dans l'un des matériaux suivants, à moins bien sûr que cela ne soit chaleureusement reçu.
Je suis content d'être à plein régime, car c'est le travail que j'aime, que je n'ai pas peur de faire le week-end, et que je fais avec plaisir.