- Speaker #0
Salut ! Épisode spécial aujourd'hui. J'ai eu la chance de poser mon micro devant Ben Hong de la Core Team Vue.js pendant la Vue.conf en mai. Et en cas de question, il explique ce que 90% des devs oublient s'ils veulent passer architecte. Allez, c'est parti ! Salut à tous et bienvenue dans On parle Dev, le podcast des développeurs qui veulent passer au niveau supérieur. Aujourd'hui, un épisode très spécial. J'étais à la vue ConfUS il y a 3 mois et j'ai eu l'honneur d'échanger avec Ben Hong, qui est évangéliste chez Netlify, qui fait partie de la core team VGS et surtout qui est une des personnes les plus inspirantes de la communauté. Dans cette interview, courte mais ultra-dosse, on a parlé d'architecture front, des erreurs à éviter, des skills à développer pour évoluer et surtout comment apprendre à penser comme un architecte, même quand on est juste dev. Alors, prêt à prendre de la hauteur ? C'est parti ! Étant donné que l'interview est en anglais, après chaque question, j'ai fait un résumé de ces réponses. Et voilà, si tu veux avoir accès à l'entièreté de ces réponses, La version vidéo sur YouTube aura les sous-titres de toute la conversation. Voilà, bonne écoute. Salut Ben, merci de prendre quelques minutes pour partager tes idées avec nous. J'ai quelques questions rapides qui veulent vraiment aider les développeurs qui veulent faire la transition de développeur à architecte. Donc la première c'est selon ton expérience,
- Speaker #1
quelles sont les erreurs les plus courantes que tu vois en architecture front-end avec Vue.js ?
- Speaker #0
cherchent à partager des données sans maîtriser les bons outils. Donc le résultat, c'est qu'ils tombent dans des outils patterns comme le pop drilling, le even buses ou le global state, outros. La vraie solution aujourd'hui, c'est de bien comprendre le composition API et les composables. Ils permettent de mieux organiser et réutiliser son code. Ok, super intéressant. Donc maintenant, si... Un développeur veut devenir architecte. Quelle est la qualité de la compétence la plus importante qu'il doit développer ? Oui,
- Speaker #1
je dirais que, de mon expérience, c'est vraiment la connaissance et l'autorité d'apprendre les défauts des différentes techniques que nous utilisons dans le développement du software. Je pense que, surtout en avant, quand les gens commencent à programmer, ils apprennent de nouvelles techniques, ils sont comme « oh, MVC » ou ils apprennent un paradigme, Oh, c'est la bonne façon. Tout devrait être de cette façon. Mais si tu veux être architecte, tu dois comprendre si je choisis, quels sont les défis ? Quand est ce que ce n'est pas une bonne idée de faire ça ? Et est ce que ça s'applique au problème que je cherche à résoudre ? Et donc apprendre à distinguer entre Oh, ce serait sympa de construire sur un projet de côté versus est ce une bonne idée pour l'application que je construis pour les clients ? Et ce sont deux choses très différentes. Et donc, oui, avoir et donc l'initiative de apprendre à faire ça. Donc... Parce que, en tant qu'ingénieur de software, il y a seulement tellement de projets sur lesquels on peut travailler. Et donc, lire les blogs d'autres personnes quand ils parlent de leurs patterns de migration, leurs problèmes, prendre le temps de les apprendre va vous aider à vous équiper de plus de connaissances sur comment résoudre ces problèmes dans différentes industries et sur les délais.
- Speaker #0
Ici, il explique qu'il faut apprendre à évaluer les compromis. Être architecte, ce n'est pas appliquer des patterns à l'aveugle, c'est comprendre quand et pourquoi une technique... technique est adaptée ou non. Il faut aussi apprendre à faire la différence entre un site project qui est fun et un vrai produit destiné aux utilisateurs. Pour progresser Ben recommande de lire les retours d'expériences, les blogs, les cas concrets, pour apprendre à passer au-delà de son propre code. D'accord. Super intéressant. Dans ton workshop, tu as parlé de patterns pour les apps vues prêtes pour la production. Selon toi, quel est le pattern que tout développeur devrait absolument maîtriser ?
- Speaker #1
Je pense que pour le code, les choses que je pense que tout le monde doit connaître pour Vue.js c'est l'utilisation des composables. Cela rend tout plus facile de créer des codes modulaires qui peuvent être utilisés dans votre application sans effets. Vous pouvez être très intentionnel et déclarer où sont vos imports. Mais sur un point de vue plus léger, je dirais l'opportunité de penser critiquement. Comme nous le savons, l'AI est une partie plus grande de notre chaine de outils ces jours-ci. Et les développeurs l'utilisent pour imposer des codes et écrire des choses. et donc être capable de penser à ce que le code est de la façon dont le code est écrit, si c'est une bonne idée d'utiliser ce code, ou peut-être qu'il y a une façon meilleure, pas seulement parce que l'AI t'a dit que ça fonctionne, mais que ça va fonctionner pour le contexte qui m'intéresse pour mes utilisateurs. Et ça va être très critiqué, je pense, en allant vers les ingénieurs de la software.
- Speaker #0
De point de vue technique, les composables sont la base qui permettent un code modulaire, réutilisable et sans effet de bord. Mais au-delà du code, la vraie compétence à développer, c'est la pensée critique. savoir si une solution, même si elle est générée par l'IA, si elle est vraiment adaptée au contexte et aux besoins des utilisateurs. C'est exactement ce que je pensais. J'en ai parlé dans mon podcast.
- Speaker #1
J'adore ça.
- Speaker #0
Les développeurs pensent souvent en termes de code, mais un architecte, lui, il pense produit. Est-ce qu'un développeur peut apprendre à penser produit ?
- Speaker #1
Oui. Quand je pense aux développeurs en termes de produit, Je pense que la chose clé ici est que, comme tu l'as dit, les développeurs pensent au code. Le produit est en deux parties. Il y a un, les utilisateurs, pensant à comment ils l'utilisent, mais deux, en se souciant de vos stakeholders. Et ça, souvent, c'est la leadership et le management. Parce qu'ils ont une raison financière pour la construction. Et donc, une autre façon de le dire, c'est que vous devez penser à vos utilisateurs et à la entreprise. Si vous ne pensez qu'à le code, vous ne serez jamais juste un développeur. Mais si vous voulez penser holistiquement et commencer... avoir plus d'impact dans votre organisation, vous devez apprendre à parler à l'utilisateur ainsi que à votre leadership dans le domaine du business.
- Speaker #0
Alors, la réponse est très claire. C'est oui et c'est même essentiel. Il faut arrêter de penser uniquement au code et commencer à penser aux utilisateurs et au business. Le produit, ce n'est pas juste l'interface. C'est aussi ce que l'utilisateur veut et ce dont a besoin l'entreprise. Pour avoir plus d'impact, un développeur doit apprendre à parler aux utilisateurs, aux managers et aux business. Super intéressant. Voilà, c'est tout. Merci, c'était vraiment intéressant. Je pense que les auditeurs vont aimer. Dernière question. Où est-ce qu'on peut te suivre pour en savoir plus sur toi ?
- Speaker #1
Oui, si vous regardez sur Internet, je suis sous le monoclase Ben Codezen. Donc, B-E-N-C-O-D-E-Z-E-N. Il y a aussi mon site, bencodezen.io. Tous mes réseaux sociaux sont là, et vous pouvez toujours me trouver. Je suis très impliqué dans Open Source, donc, n'hésitez pas à me contacter. Je suis toujours heureux de parler. Merci. Merci à toi.
- Speaker #0
C'était vraiment un plaisir de t'avoir. Merci.
- Speaker #1
Merci beaucoup. De rien. Merci de m'avoir mis en place.
- Speaker #0
Merci.
- Speaker #1
Super.
- Speaker #0
Probablement, je ne sais pas toi, mais perso, je pourrais l'écouter toute la journée. Je le trouve super inspirant et c'est vraiment plaisir de l'écouter. Si tu as aimé ce format interview, dis-le-moi. J'en ai encore plein et j'ai plein d'idées en stock. Et surtout, retiens bien ce message. Coder, c'est bien. Mais penser produit, comprendre les enjeux business, c'est ce qui fera de toi un vrai architecte. Tu peux retrouver Ben sur les réseaux sociaux. ou sur son site web bencodzen.io Je mettrai tous ces liens dans la description. Et si tu as envie de progresser, d'évoluer vers un rôle plus stratégique, abonne-toi à Podcast. C'est gratuit. Et puis viens me dire sur LinkedIn ce que tu retiens de l'épisode et ce que tu aimerais aborder. Un grand, grand merci d'avoir suivi l'épisode jusqu'au bout et à bientôt.