Quand les programmeurs voient le concept de « full stack », ils ont probablement deux réactions

1. Bon sang, c'est génial, c'est une tuerie !

2. Mais qu'est-ce que tu en sais ? Full stack, ça veut juste dire être médiocre en tout

Les deux réactions ci-dessus sont en fait biaisées. Car même si vous n'apprenez qu'une seule technologie, il y a plein de gens qui y sont catastrophiques, et parmi les ingénieurs full stack, il y en a pas mal qui font tout et le font bien. Sans compter qu'il existe un autre type de programmeur « stack-bursting » dans ce monde, qui excelle dans tout ce qu'il fait.

À partir de ma pratique personnelle,un apprenti full stackdoit maîtriser au moins les compétences suivantes :

• Développement front-end web — maîtriser au moins un framework front-end ;
• Développement back-end serveur — maîtriser au moins un framework back-end ;
• Opérations serveur — maîtriser la configuration et la maintenance des serveurs Linux ;
• Développement client — maîtriser au moins l'un des deux, iOS ou Android ;
• Bases de données — maîtriser les bases de données SQL et noSQL.

Et obtenirle titre de « full stack »devrait au moins exiger de construire seul un produit, de véritablement faire l'expérience d'opérations commerciales, et de s'être fait avoir d'innombrables fois par sa proprestupidité.

De là, on peut voir que la barre du full stack est assez haute. Ce n'est pas en maîtrisant les cinq compétences ci-dessus qu'on est qualifié de full stack ; il faut au moins ajouter « apprenti » pour le nuancer. C'est précisément parce que trop d'apprentis se disent full stack que les autres pensent que « full stack » est synonyme de « médiocre en tout ».

Cependant, le titre de cet article est — pourquoi vous devriezessayerle full stack, donc ce que je veux aborder, ce n'est pas s'il faut être full stack, mais le fait d'essayer.

Profanes et initiés

Ces dernières années, j'ai discuté avec de nombreuses équipes et j'ai constaté que la grande majorité des conflits d'équipe surviennent parce que—

• Les personnes côté serveur ne comprennent pas le client, donc après avoir conçu une API, elles racontent n'importe quoi ;
• Les designers ne comprennent pas le client, donc ils conçoivent des interactions en racontant n'importe quoi ;
• Les personnes côté client ne comprennent pas le serveur, donc elles racontent n'importe quoi à propos de l'API ;
• Les personnes côté client ne comprennent pas le produit, donc elles racontent n'importe quoi à propos des exigences ;
• Les chefs de produit ne comprennent pas les exigences, donc ils racontent n'importe quoi à l'équipe.

Sauf que les chefs de produit du dernier cas devraient être brûlés au bûcher, les quatre premiers conflits sont encore rattrapables.

La programmation est un métier de type « mode dieu » ; le travail quotidien est la création, donc ce métier paraît très cool. Cependant, c'est précisément pour cela que les programmeurs sont plus ou moins un peu arrogants.Le résultat de l'arrogance est d'utiliser ses propres connaissances limitées pour spéculer sur la façon dont le travail des autres devrait être fait.。

Si le côté serveur ne comprend pas le client, il est très facile de concevoir une API qui ne correspond pas aux mécanismes du client. À ce moment-là, si le programmeur côté client explique patiemment, et que chaque API prend un jour ou deux à peaufiner, c'est encore acceptable ; sinon, cela mène à des disputes.

Mais les programmeurs côté serveur n'ont pas toujours tort. Le côté client veut que toutes les données soient livrées sans nécessiter de traitement supplémentaire, mais si les données sont structurées comme le client le souhaite, certaines requêtes peuvent prendre une ou deux secondes. Si le côté client ne comprend pas les mécanismes côté serveur et exige aveuglément selon le principe que « le serveur existe pour servir le client », les disputes deviennent à nouveau difficiles à éviter.

Si les disputes entre techniciens sont une guerre à l'arme blanche, alors rencontrer un chef de produit ou un patron encore moins professionnel signifie qu'une guerre nucléaire éclate.

« Tu ne fais que modifier une page web — tu peux le faire en dix minutes ? »

« Comment l'effet pourrait-il bien être difficile à réaliser ? Laisse-moi le faire pour toi ! »

« Lancement demain, dépêchez-vous ! »

« Je me fiche des difficultés techniques que vous rencontrez, il faut que ça se fasse ! »

Et ce genre de scène se joue constamment dans presque toutes les entreprises.

Essayez de comprendre la technologie de l'autre partie

Laissez-moi d'abord parler de mon parcours de croissance technologique.

J'ai commencé à utiliser Linux au collège ; mon système principal était Ubuntu. Plus tard, je suis passé à ArchLinux, puis revenu à Ubuntu, et j'ai continué à l'utiliser jusqu'à ma première année d'université. Ces années d'expérience avec Linux ont posé les fondations de mon architecture serveur. En première année, j'ai commencé à essayer de construire mon propre produit.

À ce moment-là, je pensais que je devais d'abord écrire une version web, puis écrire un client.

J'ai donc commencé par le back-end, en utilisant Django comme point de départ, mais je suis rapidement passé au camp de Rails. Le développement agile de Rails a énormément réduit les coûts de développement, et ses habitudes fondées sur les conventions ont aussi permis aux débutants de survoler sans danger de nombreuses zones dangereuses.

Lorsque j'ai commencé à écrire le front-end web, je ne savais pas que des frameworks front-end existaient. Ce n'est qu'après avoir terminé avec Rails que j'ai découvert quelque chose appelé Ember.js, alors j'ai commencé à réécrire avec Ember.js. Ma compréhension initiale était encore de savoir comment utiliser Rails pour rendre le front-end, mais j'ai ensuite réalisé qu'après l'introduction d'un framework front-end, le rôle de Rails était déjà devenu celui d'un serveur API.

À partir de là, j'ai commencé à réfléchir avec une nouvelle perspective à la conception de l'API de Rails. J'ai lu beaucoup de documents sur la conception d'API — comment concevoir le front-end pour qu'il soit facile à utiliser, comment réduire le temps de requête, la mise en cache serveur, redis, la sécurité, etc.

L'automatisation de Rails a beaucoup aidé ; elle s'était déjà occupée de nombreuses choses que je ne connaissais même pas. Et quand on veut les comprendre, on découvre que l'implémentation est si ingénieuse. Sans parler de l'ouverture de Rails aux nouvelles technologies, ce qui signifiait qu'il y avait toujours quelque chose de nouveau avec quoi jouer. CoffeeScript et Sass ont d'abord été adoptés par Rails comme technologies front-end par défaut de son framework.

Plus tard, je suis passé d'Ember.js à Angular.js et j'ai tout réécrit avec Angular. Pendant cette période, j'ai aussi découvert l'outil front-end Grunt (le front-end évolue à un rythme effréné ; les outils utilisés aujourd'hui ne sont plus celui-ci).

Finalement, j'ai commencé à développer un client iOS. À ce moment-là, l'implémentation d'interface iOS était très différente du HTML et du CSS web, j'ai donc passé beaucoup de temps à comprendre les concepts d'interface iOS et à convertir ma façon de penser du développement web vers le développement d'interfaces iOS.

Pendant cette période, la base de données est aussi passée de MySQL à MongoDB, car la tendance de ces années-là était justement ce changement.

Heureusement, j'étais le seul dans ce processus technique pratique, donc il n'y avait personne avec qui me disputer. Sinon, je pense qu'il y aurait eu beaucoup de choses qui vaudraient la peine de se disputer à chaque étape.

Après la mise en ligne du projet que j'ai développé, à mesure que la complexité des opérations augmentait progressivement, je suis entré en contact avec des outils d'opérations automatisées comme Chef et Ansible. Ensuite, des services de supervision comme NewRelic ont également été ajoutés, et pour un environnement de développement stable, j'ai utilisé Vagrant.

Tout cela s'est produit en seulement un an.

Fait intéressant, plusieurs fois, pendant que j'écrivais le client iOS, j'ai soudainement compris les principes d'implémentation du HTML et du CSS ; pendant que je travaillais sur Rails, j'ai soudainement pensé à de meilleures approches d'architecture iOS. La sensation de faire des analogies entre différentes technologies se produisait chaque jour.

Dans la période suivante, cette expérience a rendu la communication avec différents techniciens très facile pour moi, parce que l'année dernière,pour le développement du filtre de Miaoshi, j'ai commencé à étudier openGL, et après avoir réacquisBlender, après l'avoir réacquis, de nombreux endroits que je ne comprenais auparavant qu'à moitié sont soudainement devenus aussi simples à implémenter que Hello World. J'ai donc simplement commencé à m'amuser avec Unity aussi. Après toute cette accumulation, apprendre Unity est devenu très facile, et c'est devenu mon projet de loisir du soir. Peut-être que bientôt, vous verrez un jeu que j'ai créé (ce sera peut-être un RPG).

Je ne pense pas que le full stack fasse de vous quelqu'un de médiocre dans tous les domaines. Quand vous travaillez avec chaque technologie, elle peut fournir des idées pour d'autres technologies. Et à condition que vous compreniez diverses technologies, approfondir l'une d'elles peut souvent nourrir en retour les autres technologies. Au contraire, si les technologies que vous comprenez sont très limitées, c'est probablement la véritable raison qui limite votre potentiel.

Respect et Paix

Dans la communication d'équipe, comprendre la technologie de l'autre partie peut considérablement réduire les coûts de communication et apporter respect et paix.

Il est rare de voir des maîtres se disputer pour savoir qui doit céder. Au contraire, ce sont généralement ceux qui viennent d'entrevoir le domaine qui se disputent sans fin toute la journée et explosent à la moindre provocation.

Bien qu'il soit difficile d'affirmer que le niveau de toute l'industrie puisse rapidement changer qualitativement, je pense que si les exigences produit peuvent être décrites avec précision et détail, avec les raisons expliquées, que les techniciens peuvent apprendre les uns des autres et discuter patiemment, et que les designers peuvent respecter la dimension technique et concevoir des prototypes mieux adaptés au présent, alors tout ira dans le bon sens. Tout commence par la compréhension du travail de l'autre.

Auteur :Zhou Kaiwen

URL de l'article original : http://www.ifanr.com/551905