Développer, c'est plus qu'un langage ou un framework.
C'est comme dire qu'il suffit de connaître la grand-mère française pour écrire un livre.
Non, il faut plus que ça !
Je sais que ce sont les technos qui sont mis en avant dans un CV.
Les langages, les frameworks.
Quand on cherche un job ou quand un client cherche un développeur, c'est le premier critère.
Quand tu t'inscris dans une école, on t'explique que tu vas maîtriser un langage
et donc que tu vas trouver un job.
Ces dernières années, Javascript fait une belle percée avec tous les frameworks frontes.
Ok.
Dans la même manière qu'ils sont venus détrôner d'autres langages ou frameworks,
d'autres viendront derrière.
Le souci, c'est que ce n'est pas parce que tu connais un framework ou un langage que tu sais développer.
C'est nécessaire, mais insuffisant.
Les langages sont souvent orientés aux objets.
Et comme ils reflètent une certaine réalité physique,
tu pourrais penser que c'est naturel de les manipuler.
Que c'est facile de les concevoir.
Eh bien non, en fait, cela demande de la technique, une technique qui va bien au-delà d'un langage.
Ce type de compétence est une compétence profonde au sens de Karl Newport.
La capacité au travail profond devient de plus en plus rare au moment précis,
où il a de plus en plus de valeur dans notre économie.
En conséquence de quoi, ceux qui cultiveront cette compétence
et en feront le cœur de leur habitude de travail,
prospèreront.
En travaillant ce type de compétence, tu travailles directement ton employabilité
et donc ta carrière.
Ta carrière, c'est l'évolution de ton salaire et l'intérêt des missions qui te sont confiées.
Imagine maintenant une journée malheureusement trop banale.
Tu démarres ta session de développement, tu as les idées claires sur ce que tu veux faire,
mais pas forcément sur comment tu vas le faire.
Ça touche une partie du code que tu ne connais pas et tu as peur de casser quelque chose.
Tu sais déjà que la journée va être long.
Tu te lances, tu cherches à comprendre où tu pourrais te brancher.
C'est laborieux, mais enfin tu trouves.
Fatigué, tu fais une poste café.
Bon, tu tiens mais.
Et tu codes la nouvelle fonction.
Comme t'es un peu coincé dans ce code legacy que tu n'auses pas trop touché,
tu fais au mieux pour coder ce que tu avais en tête.
Mais tu livres sur develop et tu montes ça à ton PO.
Malheureusement, il y a pas mal de trucs à revoir
et ça va t'obliger à reprendre les morceaux que tu n'avais pas envie de toucher.
Tu vous la montres et tu y retournes faire une pause.
Bon, mais il faut y aller.
Tu t'attaques au gros morceau.
C'est une bataille épique, est stressante, mais tu finis par y arriver.
Bon, ça dit épuisant, mais tu pourrais presque être satisfait.
Le seul X, c'est que tu viens d'ajouter trois bugs dans un critique dans l'application.
Et finalement, tu rentres chez toi frustré de ton travail.
Avec ce que je vais te raconter,
tu es concerné si tu as la trouille de changer quelque chose.
Quand tu corriges un bug, deux autres apparaissent.
Ton boss te demande d'en faire toujours plus.
Et c'est de plus en plus difficile.
Si tu as récupéré un code legacy, si tu arrives à même à perdre le plaisir de coder.
Et pourtant, on sait qu'on peut faire un job qui peut être tellement épanouissant.
Maintenant, imagine une nouvelle journée.
Tu commences ta session de développement.
Tu as clarifié ta user story et t'es prêt à y aller.
Tu te sens complètement serein parce que tu sais déjà que ça va bien se passer.
Tu démarres ta nouvelle fonction et tu te plonges à fond.
Le travail est fluide.
Tu es tellement concentré que tu ne vois pas leur passer.
Tu es dans le flux totalement absorbé parce que tu fais.
T'es neuro carbure à fond et c'est bon.
À la fin d'une longue session de travail, tu livres ça sur develop.
Tu fais une démo à ton PO qui apporte quelques ajustements.
Tu corriges et pouf, c'est prêt à passer en validation.
C'est facile et direct.
Tu finis tes journées avec la satisfaction du devoir accompli.
Tu es fier de ton travail.
Alors je te préviens, ça peut être un chemin long et parfois difficile.
J'aimerais pouvoir te vendre une carte SD qui t'apprenne à écrire du code durable.
Tu aurais juste à la brancher à ton cerveau et tu téléchargerais tout, mais ça ne marche pas comme ça.
C'est long à apprendre.
C'est pas tard la théorie qui prend du temps, c'est surtout la pratique.
Et c'est lent comme toute compétence profonde.
C'est parfois difficile aussi.
Il faut accepter de remettre en question les croyances
et redevenir débutant.
Pas facile et même douloureux parfois,
sans compter les vrais mots de tête quand ton cerveau s'ature.
Alors si tu n'es pas prêt à faire ses efforts,
tu peux arrêter d'écouter la vidéo là.
Mais si tu es prêt à te dépasser pour rendre ta carrière de développeur épanouissante,
à augmenter ta confiance en ton code
et à prendre du plaisir à faire un job qui te rende fier,
alors tu es au bon endroit.
Car tu n'es pas obligé d'être seul pour traverser tout ça.
Je suis passé par là et je peux t'accompagner à faire ce chemin toi aussi.
Pour ça, j'ai créé le Cursus Artisan Developer
et il a déjà été des dizaines de développeurs à progresser.
Et ce Cursus ouvre ses portes aujourd'hui jusqu'à dimanche.
D'ailleurs, voici un extrait du témoignage de Jean-Maxime Boulogue, développeur.
Franchement, c'est une très bonne formation.
J'y allais pour apprendre un peu plus de bonnes méthodes
et de bonnes façons de faire pour coder,
notamment au niveau des tests unitaires.
Je n'ai pas été déçu.
J'ai vraiment appris énormément sur les tests
et aussi sur d'autres façons de faire, d'organiser son code.
J'ai également récolté le feedback de plusieurs développeurs
lors des sessions d'accompagnement.
Je t'ai mis que les prénoms,
tout simplement parce que je ne leur ai pas demandé explicitement leur accord,
à contrario de ceux qui ont bien voulu m'envoyer un témoignage vidéo.
J'ai mis le détail de ces verbatimes dans la description du Cursus.
Tu trouveras le lien dans la description de cet épisode.
Je t'invite à la consulter pour te faire une meilleure idée
de ce que le Cursus peut apporter.
Bon, et pour se faire plaisir,
voici un autre extrait de témoignage,
celui d'Emmanuel Rich, développeur.
On aborde tout un tas de sujets qui sont autour du Crapman Chip,
qui posent des bases pour écrire du code propre, maintenant,
et surtout à usage des utilisateurs directement
et qui va supporter plusieurs mises à jour.
Donc vraiment, suivez-le.
C'est des compétences qui n'auront jamais,
parce que tant qu'il y aura du quoi décrire,
ce qui y est abordé, ce sera toujours valable.
Le Cursus complet se découpe en 8 modules.
Les 3 clés d'un code durable.
Ranger chaque objet à sa juste place.
Tenter les dépendances.
Le cœur du réacteur.
Reprendre le contrôle du legacy.
Communiquer avec le métier.
Piloter aux instruments.
Et les pratiques d'équipe.
Chaque module est construite avec 3 outils.
Les vidéos, les quizzes, les exercices.
Les vidéos sont soit théoriques, soit pratiques.
Je commence par te donner les éléments théoriques,
puis je les illustre par un cas concret.
Tu peux voir comment j'applique la théorie
et je te donne les clés pour l'adapter à ton contexte.
Libre à toi de faire comme moi ou trouver ton propre style.
C'est vraiment un élément important du Cursus
et ça fait partie intégrante de la pédagogie.
Si d'ailleurs un point n'est pas assez clair,
dis-le-moi.
Et soit je rajoute ce qui manque,
soit je précise mon propos.
Par exemple, la version 1.0 contonnait trop point de catade,
illustration du TDD,
et ce sera corrigé dans la version 1.2.
Les quizzes sont là pour ancrer les connaissances
et les exercices pour te permettre d'aller plus loin à ton rythme.
A tout moment, je reste avec toi par email
si tu as un doute, une question,
ou simplement que tu as envie de partager ton travail.
Tu m'envoies un email et je te réponds.
Cette formation te donne accès aux 8 modules
ainsi qu'au miséjour à venir.
Et comme tu pourras le constater dans le release note,
je travaille sur ce Cursus depuis un moment
et je continue à le faire évoluer au fur et à mesure des retours.
Alors ce Cursus est le fruit de plusieurs années
à le construire et à l'affiner.
De centaines d'heures de lecture,
de milliers d'heures d'expériences accumulées
pendant 20 ans de carrière.
Alors tu as le choix entre lire des tonnes de livres
et tâtonner pendant des années,
ce qui est une bonne option.
Ou alors tu n'as pas ce temps
et tu veux en condenser structuré
que tu vas directement pouvoir mettre en œuvre concrètement.
Cette formation contient environ 8 heures de cours en ligne condensées.
Attention, une heure de cours en ligne structurée
est beaucoup plus dense qu'une heure de formation classique.
Et avec les exercices et les quizzes,
il faut prévoir l'équivalent d'environ
une semaine pleine de formation.
Après, tu vas à ton rythme et tu le consommes comme tu veux.
Si tu te contente d'écouter les vidéos en x2,
tu n'en auras pas le même bénéfice
que si tu travailles chaque exercice que je te donne.
Ça, c'est évident.
En plus, cette fois, j'aime bien lire le Cursus avec 2 dojeux bonus,
le 3 décembre de 13h à 14h30.
Il est 14 décembre de 13h à 14h30.
J'ai un peu éloigné les dates
pour faire en sorte que ça te laisse le temps d'absorber
tout le Cursus au moins jusqu'au module 4.
Ces dojeux seront ouverts à tous les clients du Cursus présent et passé.
Et si ça te plaît, je pourrai les reconduire
et pourquoi pas en faire régulièrement.
On travaillera à priori sur un Cata
ou sur du Code réel partagé par un départicipant.
Et mon expérience me montre que ces dojeux apportent beaucoup de valeur
dans les échanges qu'ils génèrent.
Et puis, ce sera l'occasion de rencontrer d'autres apprenants du Cursus.
Et pourquoi pas continuer entre vous.
Bon, alors tout ça, ça va changer quoi dans ta vie?
Grâce à ces Cursus et un peu de travail,
tu pourras éradiquer les bugs dans ton application,
mettre en prod comme tu mettrais une chemise propre,
passer plus de temps à créer de la valeur qu'à jouer à l'archéologue,
supprimer le debugger de ton quotidien,
innover en permanence et prendre 3 longueurs d'avance sur la concurrence
ou venir le matin au boulot avec un sourire insolent,
bâtir sereinement une application durable
et refactorer ton code en continu pour l'améliorer.
A contre, à Rio, qu'est-ce que ce Cursus ne t'apportera pas?
Ce Cursus n'est pas une liste de choses à suivre à la lettre.
C'est un cadre de réflexion à t'approprier.
Si tu cherches quelqu'un qui te dise exactement étape par étape ce qu'il faut faire ou ne pas faire,
tu peux passer ton chemin.
Si par contre tu cherches quelqu'un qui t'apprenne à réfléchir par toi-même
pour t'adapter à chaque situation, tu es au bon endroit.
De la même façon, tu ne trouveras pas d'exemple dans tous les langages de la Terre.
Donc a priori, pas dans ton langage préféré,
sauf le Gatha Greetings qui a été traduit dans de nombreux langages par la communauté.
Et c'est pas grave, j'utilise des langages de manière extrêmement basique.
Pas de furiture. Je choisis des langages simples qui parlent à tout le monde.
Java et Dart, pour le moment, et je n'utilise aucun framework.
Encore une fois, le langage employé n'a pas d'importance ici.
Les exemples ne sont là que pour illustrer les concepts que l'on voit dans les vidéos.
Ils sont pédagogiques car ils traduisent concrètement ce que l'on aborde,
mais le langage employé est secondaire dans cette formation.
Bon, avant d'entrer dans le détail du cursus, juste pour le plaisir,
on se met à notre extrait d'un CTO content d'avoir suivi le cursus avec son équipe.
Il s'agit d'Artur Main, CTO chez Promise.
Pour moi, ça a été un bon initiateur de changement dans l'équipe.
Parce qu'on travaillait depuis 4 ans sur la même base de code
qui évoluait de manière assez limère.
On ne se posait pas vraiment de question sur la manière vraiment d'écrire notre code et nos pratiques.
On a vu un réel changement pendant et après le cursus,
on a eu plus envie de se poser des questions qu'on ne se posait pas forcément au début.
Est-ce que ce qu'on est en train d'écrire, on l'écrit de la bonne manière ?
Est-ce que les pratiques qu'on a en place, c'est vraiment les meilleurs
pour que notre code soit évolutif, maintenant, dans l'avenir
et surtout qui génère pas de bug lorsqu'on fait une évolution ?
Entrons maintenant dans le détail des modules.
Modul 1, les 3 principes clés d'un code durable.
Dans ce module, tu apprendras les principes de base d'un code vraiment évolutif.
On t'a fait croire qu'il fallait tout anticiper à l'avance,
tu verras que c'est tout le contraire.
Dans ce module de formation, on voit la grande loi immuable qui explique
pourquoi rien ne se passe jamais comme prévu.
Les principes pour développer du code et un logiciel de qualité qui va durer dans le temps,
comment préparer l'avenir en se concentrant sur aujourd'hui,
comment amener son manager à investir dans un bon design,
comment le plus grand mensonge de notre industrie continue de nous pourrir la vie,
l'état d'esprit pour développer du code propre et professionnel
et pourquoi le scrum seul est insuffisant pour gérer un projet logiciel.
On n'entre pas encore dans le code mais on pose le référentiel de travail.
Module 2, ranger chaque classe à sa juste place.
Quand tu utilises un langage objet,
tu peux avoir l'impression que les objets sont naturels, qu'ils sont faciles à créer.
C'est comme dire que parce qu'un téléphone ou un ordinateur est facile à utiliser,
c'est facile de le fabriquer.
En fait, non, c'est tout le contraire.
C'est difficile de créer des objets qui sont faciles à utiliser.
Dans ce deuxième module, on entre en plein dans le code et on voit
comment mettre en œuvre concrètement le principe de responsabilité unique,
comment détecter qu'une classe fait trop de choses et comment la décomposer,
comment appliquer concrètement les designs paternants du code de production,
comment partir dans le pot de code confus pour l'améliorer en faisant émerger les concepts,
comment utiliser le principe dry et ton intestinomètre,
quand on prend une décision ou ne pas la prendre,
mais trois patterns de refactoring favoris pour transformer n'importe quel bout de code
aussi moche fatile en un code de première classe.
Après s'être occupé d'une classe, on pourra voir les interactions entre classes dans le prochain module.
Et justement, module 3, dompter les dépendances.
Dès lors que tu as plus d'une classe dans ton projet,
tes classes ont une interdépendance.
Et c'est là que les choses se compliquent.
Car si tu ne gères pas les dépendances correctement,
tu te retrouves avec du code difficile à faire bouger
et le spaghetti monster te dévore tout cru.
Alors pour dompter les dépendances, on voit dans ce module
pourquoi il vaut mieux dépendre d'une interface que d'une classe concrète,
avec la métaphore du bouton vert,
comment démêler les dépendances intriguées,
les trois design patterns que j'emporte partout avec moi et...
non, 5 le tons n'en fait pas partie.
Mais quatre techniques pour gérer les dépendances,
comment utiliser la loi des démetteurs pour débusquer les dépendances à problème.
À ce stade du cursus, tu es prêt à passer au plat de résistance le TDD.
Module 4, le cœur du réacteur.
Les tests unitaires, c'est important et pourtant tu n'en écris pas.
Ça fait peut-être même partie de ta définition de terminer
la règle dans le scrum qui dit « quand tu as fini une story ».
Mais en réalité, personne n'en écrit vraiment.
Alors soyons clairs, les tests unitaires,
c'est pas un truc important, c'est le truc fondamental dans ma méthode.
C'est la base de la stratégie de test.
Avec des tests, tu éradiques les bugs, t'es ultrascène,
tu peux refactorer ton code à volonté ayant continu.
Les tests unitaires, c'est le premier pas vers un monde épanouissant,
et oui, le monde des bizounours existent.
Les tests, c'est la vie du code.
Dans ce module, je t'apprends à écrire tes premiers tests unitaires.
Je t'explique pourquoi tester c'est douté,
mais je veux dire vraiment, quels sont les différents types de tests,
comment structurer un test, quels sont les critères dans le bon test.
Je te montre aussi ma manière de résoudre plusieurs cas-tas
pour illustrer concrètement la démarche.
On aborde aussi la dimension psychologique,
qui joue un rôle essentiel dans l'adoption de cette pratique.
On y parlera bien sûr TDD,
qui est pour moi la seule manière d'écrire des tests valables.
Mon objectif est que tu sois en capacité d'écrire tes premiers tests
d'ici la fin du module.
Alors attention, c'est clairement la partie la plus difficile du cursus.
En théorie, c'est simple,
mais la mise en pratique est vraiment très difficile.
Et c'est là que la plupart des gens calent.
Mais ça serait dommage de s'arrêter là,
t'es à deux doigts de transformer ton quotidien.
Alors c'est pour t'aider à franchir ce cap
que j'intègre dans le cursus de session de coding dojo.
Ensemble, on lève les derniers freins qui t'empêchent de sauter le pas.
En effet, une fois que tu as atteint le niveau 4,
tu peux participer aux différentes dojo qui sont programmées.
Module 5, reprendre le contrôle du legacy.
Le code legacy, c'est pas toujours le pied.
Il est peut-être pas merveilleux, mais il a le mérite d'exister.
Attendre la grande réécriture n'est certainement pas la solution
à tous les problèmes du code legacy.
En effet, les projets neufs ont trois inconvénients majeurs.
D'abord, rien ne garantit que tu vas pas refaire
les mêmes erreurs qui aboutiront au même résultat.
Dans 6 mois à un an, tu te retrouveras dans la même situation qu'aujourd'hui
si tu ne changes rien.
Ensuite, ils sont rares.
Ce n'est pas tous les jours qu'une boîte décide de se lancer
dans un chantier de refonte, alors que chaque jour
est l'occasion de s'améliorer.
Enfin, ils sont longs à sortir.
En général, le projet de refonte doit attendre
d'atteindre un certain niveau fonctionnel
avant de remplacer le système legacy.
Et pendant ce temps, il faudra bien continuer à faire avec le vieux code.
Dans ce module, on aborde les raisons cachées
qui rendent le SpaghettiMonster si puissant,
la règle d'or à suivre, telle un fil d'arienne
dans une tempête de sable, les techniques du Ninja
pour t'en sortir dans n'importe quel code,
les différentes techniques pour reprendre la main
sur du code legacy impropre au test
et le rendre progressivement testable.
On va pas se le cacher, c'est la partie la plus dense,
mais c'est aussi celle qui se sauvera la mise
quand tu devras attaquer un projet legacy.
Modulcise communiquer avec le métier grâce au BDD.
As-tu déjà remarqué
comme la spec était un sujet courant d'embrouille sur un projet ?
Si en plus c'est ce qui définit le cadre commercial,
les choses peuvent devenir rigides.
Pour moi, une bonne spec remplit les critères suivants.
Elle capte le besoin de business,
elle sert de pivot avec le développement,
elle est vivante, c'est-à-dire transformable en test,
et elle sert de documentation de référence.
Dans ce module, je te montre comment utiliser le BDD
et le transformer en un véritable levier de communication
avec ton client.
Je te montre aussi concrètement comment je l'utilise au quotidien
depuis des années pour mener à bien mes projets.
Après ça, s'en est fini,
des hame-voyons, c'était évident, qui pourrissent l'ambiance.
On maximise les chances de se comprendre
et faire circuler la connaissance dans l'équipe.
Module 7 piloter aux instruments.
Les outils de mesure, c'est un peu comme les instruments
du pilote de ligne.
Ils lui permettent de naviguer sans voir ce qui se passe dehors.
Grâce à ces outils, on prend du recul sur le code
pour mieux l'analyser et l'améliorer.
Dans ce module, je t'explique à quoi servent les lineteurs
et comment les utiliser efficacement.
On passe aussi en revue quelques métriques les plus répandus,
comme la complexité cyclométrique et la couverture de code.
Ensuite, on dégomme quelques mutants à la machette
et pour finir, on voit comment intégrer tout ça
dans ton workflow quotidien avec les conseils issus de mon expérience.
Module 8 les pratiques d'équipe.
Il est fini le temps où un développeur seul
pouvait révolutionner une industrie.
Aujourd'hui, pour conquérir un marché,
il faut bien souvent plusieurs développeurs
et toute une équipe avec des compétences variées,
ce qu'on appelle aujourd'hui une feature team.
C'est là que les individus feront une grosse différence.
Vont-ils être capables de jouer en équipe
ou se la jouer solo en mode cowboy ?
Ce module est centré sur les pratiques d'équipe
qui viennent non seulement renforcer,
mais aussi amplifier les pratiques techniques
que l'on a vu jusqu'à maintenant.
On y voit notamment les quatre pratiques essentielles
du tueur de bug.
On en profitera pour profondre les mythes
et les idées fosses autour du binommage.
On voit les principes d'auto-organisation,
d'amélioration continue, de responsabilité collective,
de rythme durable, de conception émergente
ou encore du principe de petite livraison.
On voit encore les questions de règle de codage,
d'EDD et intégration continue,
cette fois sous langue non plus technique,
mais de la pratique d'équipe.
On voit aussi quelques aspects du Dark Jail
pour apprendre à débusquer les pièges de l'agilité
et enfin on visitera la dimension psychologique du code
car oui, code et propre rend heureux.
Bon, comme ça fait longtemps qu'on s'est pas mis
en extrait de témoignage,
voici celui de Rémi Privée développeur.
Ça permet de détauffer vraiment sa boîte et outils de développeur.
Donc pour le développement quotidien.
Donc ce sont pour les techniques de refactoring,
des design paternes,
la mèloration des tests internes,
notamment avec la technique du TDD.
On apprend, on approuve que faire bien
ne coûte pas plus cher.
Donc on retire de la satisfaction personnelle,
d'avoir un code plus visible,
compréhensible partout.
Et voilà, c'est un plaisir d'avoir un code
et un travail bien fait.
Le cursus est construit avec une arche pédagogique précise,
la pédagogie en escalator.
La pédagogie en escalator, c'est quand il y a un double effet.
Adopter ces pratiques, c'est difficile, on va pas se le cacher.
La courbe d'apprentissage est raide.
Donc j'ai découpé la progression en étape pour rendre ça accessible.
D'où les différents modules en escalier.
Et ensuite les premiers progrès te donnent confiance
et te gonflent de motivation à bloc
pour attaquer des problèmes de plus en plus difficiles.
C'est le moteur de l'escalator.
Je crois tellement en cette pédagogie
que j'offre une garantie satisfait ou remboursée pendant 30 jours.
Si tu n'y trouves pas ton compte,
il te suffit de m'expliquer pourquoi
et je te rembourse sans aucune autre condition.
Si tu veux connaître le détail précis de chaque module,
je t'invite à consulter la page de description du cursus
dont tu trouveras le lien en commentaire.
idem pour le fichier de release notes
dans lequel je détaille toutes les évolutions apportées au cursus depuis 2018,
ainsi que celle prévue dans les semaines et mois à venir.
Mais au fait, qui suis-je pour te raconter tout ça ?
Je m'appelle Benoît Gantot, mais je suis tombé dans la marmite de la startup
depuis les codes l'ingénieur.
Les startups sont des environnements particulièrement exigeants
sur la vélocité et la capacité d'adaptation.
Cela se traduit par des changements de direction fréquent
qu'il faut savoir gérer pour garder une base de code saine.
C'est vraiment là que j'ai appris mes techniques de survie.
Et c'est avant tout mon expérience que je partage dans les écrits
sur artisandeveloper.fr, dans mon livre
« J'ai unit l'écriture de tests automatiques »
ou encore les plus de 250 épisodes de podcasts que j'ai animés.
Développeurs, hauteurs, formateurs, vacataires, consultants
sont pour moi autant de manière différente
d'exprimer une même passion pour le code.
Bon, et ça fait pas de mal, un petit dernier témoignage
pour la route, celui de Thierry Desmorets, coach agile.
Alors moi ce qui m'a intégré plus dans ce cursus,
c'est déjà la structure, l'organisation des cours.
Vraiment je le conseille à toutes les personnes.
La démarche Craftman, c'est une super belle manière
de répondre aussi à l'agilité Scrum de la manière technique.
Donc quoi de mieux ? Allez-y, jetez-vous dans l'aventure,
vous n'en sortirez que grandit et avec de nouvelles idées
et de nouvelles pensées.
Si tu es encore là, peut-être que tu as des questions
auxquelles je n'ai pas encore répondu, alors voici
la liste des questions fréquentes.
D'abord, quelle est la différence avec les modules d'avant ?
Ces deux dernières années, j'ai mis en vente
les modules du cursus les uns après les autres.
Cette édition regroupe tous les modules en un cursus
ainsi que les mises à jour publiées depuis.
Tu en trouveras le détail dans la partie Realize Notes.
Je prévois de continuer à améliorer les supports
et la pédagogie au fur et à mesure des échanges
et de tes retours.
Si tu entres aujourd'hui dans le cursus,
tu auras accès gratuitement à toutes ces évolutions à venir.
Est-il possible de déduire du prix les modules déjà achetés ?
Absolument.
Si tu as déjà acheté certains modules du cursus,
envoie-moi un email et je te donnerai un coupon
qui dédura les montants déjà versés.
Je le générerai bien automatiquement pour tout le monde,
mais la plateforme que j'utilise ne permet pas vraiment
de l'automatiser et il y a trop de monde
pour que je le fasse à la main.
Donc si tu es intéressé, fais-moi signer.
Est-ce que ça marche si tu es débutant ?
Si tu es tout débutant et que tu n'as pas encore écrit
ton premier programme, je te conseille plutôt
de te concentrer là-dessus.
En revanche, si tu sais déjà utiliser un langage,
alors ça peut être intéressant,
même si tu es en cours du formation,
du moment que tu as du temps à y consacrer.
Ça peut même te permettre de partir sur de bons rails
plutôt que de prendre de mauvaises habitudes
qu'il faudra ensuite effacer.
Est-ce que le résultat est garantie ?
Oui.
Si tu n'es pas satisfait, je te rembourse
sous 30 jours si tu m'expliques pourquoi tu n'es pas content.
Mais si tu bosses sérieusement,
cela n'arrivera pas.
Il faut prévoir combien de temps pour finir le cursus.
Il faut environ compter une semaine pleine
pour étudier le cursus.
Mais attention, ce temps est à étaler
à raison de quelques heures par semaine.
J'en vois qu'il avale et digère le cursus en 4 semaines,
d'autres en 12.
Cela dépendra beaucoup de ton engagement,
ta motivation et tes disponibilités.
Est-ce que je peux payer en plusieurs fois ?
Oui. Il y a une option pour un paiement en 4 fois,
il suffit de choisir cette option-là
dans le moment de régler.
Quels langages sont utilisés dans les exemples ?
J'utilise pour le moment Java et Dart.
Il me semble facile à comprendre et pédagogique.
Mais je n'utilise aucune spécificité
du langage, ni aucun framework.
Le but est uniquement d'illustrer les concepts
vus ensemble dans un cas concret.
Si vraiment tu n'arrives pas à faire le lien
avec ton langage, tu me l'expliques dans les 30 jours
qui suivent ton achat et je te rembourse.
Qu'est-ce qui se passe si tu es déjà bien formé
sur tous ces sujets ? Est-ce que tu pourras en tirer quelque chose ?
De l'expérience que j'ai du cursus en entreprise,
je constate que tout le monde s'y retrouve
et tout le monde y trouve son compte.
Ceux qui découvrent ces notions apprennent
à les mettre en œuvre.
Ceux qui sont déjà familiers vont plus loin.
Et ceux qui maîtrisent ces sujets trouvent
une manière différente de les transmettre
en s'inspirant de la pédagogie.
A toi de voir la valeur que tu y cherches.
Dans le doute, envoie-moi un email
à benoîtarobaseartisandeveloper.fr
et on en parle.
D'une manière générale, si tu as d'autres questions,
il te suffit de me les envoyer encore une fois
benoîtarobaseartisandeveloper.fr
J'espère te retrouver bientôt de l'autre côté.
Il te suffit de cliquer sur le lien en description
pour en savoir plus et me rejoindre.
Pour finir, je te mets tous les témoignages vidéo
que j'ai reçus.
Merci infiniment à leur hauteur.
Déjà, je dirais que pour moi, ça a été
un excellent point d'entrée dans les bonnes pratiques
du software Cartham Archip.
C'est vrai que j'avais déjà essayé le TDD
dans une boîte précédente.
Mais en tant que suiveur, je faisais les tests
à l'endroit où on m'avait dit de faire les tests
et je ne me suis pas vraiment approprié
la pratique.
Et grâce au module sur le TDD,
qui est consommé d'ailleurs,
j'ai commencé à comprendre
pourquoi c'était important
de faire du TDD.
Puis ensuite, m'intéressais au comment
afin de mettre la pratique
et mettre en place le pourquoi.
Le cursus est très actionnable
et c'est ce que j'ai bien aimé.
Un second point,
c'est que le cursus m'a permis
d'élever mes standards.
C'est-à-dire que, par exemple,
pour moi, une bonne architecture
logicielle maintenant est une architecture
facilement testable
au sein des composants. Parce que je n'avais pas forcément
avant et si je n'arrive pas à tester,
je me dis qu'il y a un problème et je revois tout.
Troisième point important,
c'est que le cursus me sert de référence.
Je n'ai pas consommé tout le cursus d'un coup.
Je fais des petits allers-retours
entre les modules, le temps
de digérer et
le fait qu'il soit mis à jour,
c'est important aussi parce que ça me permet
d'avoir un regard supplémentaire.
Alors, pour les quelques suggestions
d'amélioration du cursus,
je pense que
des coups interactifs seraient un vrai plus
parce que
les exercices, le papier, c'est
un peu voilà.
Et augmenter
le taux de cas concret,
des exemples puis des exercices,
parce que, bien qu'il y en ait quelques-uns,
c'est vrai que, par exemple,
c'est beaucoup plus simple à mettre en place,
à recopier d'abord,
à faire avec toi puis ensuite à faire de son côté.
Bonjour, moi je suis Arthur May,
CTO éco-fondateur
d'entreprises Promise.
On est une entreprise qui comporte
7 développeurs.
Donc on a tous suivi le cursus artisan
développeur il y a un an maintenant, à peu près.
Et de suivi du cursus,
ça a été assez simple, pas vraiment
au chronophage. Chacun pouvait suivre
à son rythme sans problème.
Certaines personnes m'aiment en fond de ce qu'ils faisaient
quotidiennement. Et si je devais résumer
un petit peu ce que ça nous a apporté,
pour moi ça a été un bon initiateur de changement
dans l'équipe. Parce qu'on travaillait
depuis 4 ans sur la même base de code
qui évoluait de manière assez limère.
On ne se posait pas vraiment de questions
sur la manière vraiment
d'écrire notre code et nos pratiques.
Et on a vu un réel changement pendant
et après le cursus, surtout.
On a eu pu s'envie de se poser
des questions qu'on ne se posait pas forcément
au début. Donc est-ce que ce qu'on est
en train d'écrire, on l'écrit de la bonne manière ?
Est-ce que les pratiques qu'on a en place, c'est vraiment
les meilleurs pour que notre code soit
évolutif, maintenant, dans l'avenir
et surtout qui génère pas de bug
lorsqu'on fait une évolution.
Donc je ne me rappellerais pas
tous les concepts techniques qui sont liés
au cours. Ça n'a beaucoup qui sont distés.
Mais pour moi, ce qui est vraiment important,
c'est le mindset que ça peut apporter
à l'équipe. Et pour moi, c'est vraiment
la valeur ajoutée de ce cours. Je pense que ça peut vraiment
aider une équipe à se poser des bonnes questions
sur ces pratiques de développement
et surtout à rentrer dans une démarche forte
et d'amélioration continue.
Moi, j'ai découvert le cursus artisan-développeur
quand j'étais autodidact. Au moment où je souhaitais
faire du développement mon métier professionnel
et je me suis posé la question
de savoir si ce que je faisais
était bon. Si vraiment, c'était
une compétence que j'ai commettie
à qui tout seul, est-ce qu'elle était
suffisante une fois qu'on frottait
à la réalité et du monde professionnel ?
Et c'est là que le podcast
de Benoît et son cursus
finalement, ont répondu à ces questions.
Alors, ça a conforté mon idée
aussi que j'avais de la façon dont je souhaitais
écrire mon code.
Même si j'avais pas les bases nécessaires
pour forcément écrire du code propre,
j'avais l'envie
quand même d'écrire des tests, de savoir
comment est-ce qu'on faisait tout ça. Et ce cursus
a répondu à toutes ces questions.
En plus, c'est en français
et moi, je ne suis pas spécialement
un grammateur de langue anglaise. Donc
même s'il y a déjà beaucoup
de contenu sur ce sujet en anglais,
ce sujet en français là,
il n'y en a pas beaucoup. Donc le cursus
de Benoît, il permet vraiment
d'avoir un raccourci quand on est français
pour pouvoir accéder
plus rapidement à ce type de contenu.
Et en main
des cas concrets d'utilisation,
on aborde tout un tas de sujets qui sont
autour du Crap Man Sheep, qui posent
des bases pour écrire du code propre, maintenant.
Et surtout, à usage
des utilisateurs directement et qui va supporter
plusieurs visages au. Parce que moi, j'ai écrivé du code
avant, que c'était vraiment que pour mon usage
personnel,
personne ne le regarderait donc je me demandais
pourquoi est-ce que je l'écrivais différemment.
Ça me concerne que moi finalement.
Mais quand on rentre dans le monde professionnel
en fait, on se rend compte qu'on doit se servir
de gens. Il y a des gens qui sont en attente
de certaines fonctionnalités et qui veulent pas
ou perdre d'autres en même temps.
Donc comment est-ce qu'on fait pour
faire vivre du code en fait.
Et ce qui en suffit serait pour ces questions.
Donc vraiment, suivez-le.
C'est des compétences
qui n'aiment pas jamais. Parce que tant qu'il
y aura du quoi décrire en fait.
Ce qui y aborder, et fait, et ce sera toujours valable.
Franchement, c'est une très bonne formation.
J'ai allé
pour apprendre un peu plus de bonnes méthodes
et de bonnes façons de faire
pour coder. Notamment au niveau
des tests unitaires.
Et je n'ai pas été déçu. J'ai vraiment appris
énormément sur les tests
et aussi sur d'autres
façons de faire, d'organiser son code.
En plus,
les vidéos sont
un format vraiment très
très bien.
Ils tournent autour de 10 à 20 minutes
maximum. Du coup, on peut
regarder des vidéos
un peu à tout moment de la journée
sur la pause des jeunées et tout.
Donc franchement, je recommande
chaudement
cette formation qui m'a vraiment beaucoup appris
et qui me permet
de développer
de manière un peu plus sereine maintenant.
J'ai pris la formation d'ortison développeur parce que j'avais
des attentes précises.
Je m'étais déjà confronté
à du code legacy.
Et donc évidemment, ça a été
une catastrophe. Et au fur et à mesure que j'ajoutais
des fonctionnalités, je me suis rendu compte
que je n'avais pas à faire du code maintenant.
Donc petit à petit
je cherchais une solution par moi-même.
Je suis tombé sur la formation. J'ai pris la formation.
Et finalement, j'ai beaucoup appris.
Moi, je suis rentré principalement pour le TDD
avec notamment la promesse
de faire du code
maintenant
dans le temps
grâce au test.
J'ai eu de belles découvertes dans la formation
notamment le BDD.
Du coup, qui me permet de tester
le visuel, de tester les vues.
J'ai été assez étonné.
J'ai aussi appris au niveau des dizaines paternes
alors que j'en connaissais déjà.
Mais ça, je m'y attendais pas.
Du coup
déjà, j'aimerais
dire un grand merci. Parce qu'aujourd'hui
dans tous mes projets personnels
et professionnels,
j'utilise les tests.
Je continue à m'améliorer dans ce domaine-là
mais déjà, je les applique.
Et je remarque
que je constate vraiment une amélioration
dans la maintenance de mon code.
Donc ça, déjà cet objectif là, il a été atteint
et j'en suis très fier.
Alors, qu'est-ce qu'on peut apprendre ?
Qu'est-ce qu'on pourrait peut-être
ajouter à la formation ?
Éventuellement,
ça serait tout ce qui concerne
l'architecture du code.
Là, je suis en train de m'intéresser
au DDD, donc
Domain Driver Development.
J'ai trouvé intéressant mais je n'ai pas encore bien compris
et je pense que ça peut être
ça peut
compléter un peu plus la formation.
Ça permet de détauffer
vraiment sa boîte et outil de développeur
pour le développement
quotidien.
Donc ce sont pour les techniques de refactoring,
des design pattern,
l'amélioration des tests interne
notamment avec la technique du TDD.
On apprend, on approuve
que faire bien
ne coûte pas plus cher.
On retire de la satisfaction
personnelle, avoir un code plus lisible,
le compréhensibil par tous.
C'est un plaisir
d'avoir un code et
un travail bien fait.
Le cursus est composé d'explications
théoriques, riches,
assez riches et ensuite on a des ateliers
pratiques sous différentes formes.
C'est un moyen
de se challenger pour faire toujours mieux
que ce soit au niveau d'un nouveau code
ou d'un code qui pourrait être
obsolète ou vieillissant.
Petit pas, pas de petit pas,
on ne filme qu'un par allé loin
et bien progressé.
En suivant le cursus artisan
développeur, j'ai compris comment
et pourquoi utiliser des design patterns.
J'ai
réalisé que j'avais déjà
des bonnes pratiques en matière de refactoring
et j'ai essayé de faire du TDD.
J'en suis encore loin
mais en moins, je teste
maintenant bien mon code
aux endroits les plus touchés et ça me donne
une certaine sérénité quand
tu as au code livré
à mes clients.
Grâce à ça, je suis droit dans mes pompes
quand je leur vends une fonctionnalité
sur laquelle je dis que je vais passer
10 jours parce que je sais qu'au plus
avec le rework
ça me prendra douze jours
et
ça
permet d'être vraiment tranquille
dans mon métier. Salut les amis
Craftmen, à l'heure y a peu j'ai eu l'occasion
la chance d'avoir suivi
le cursus artisan developer par Bonoogentum.
Alors moi, ce qui m'a étonné
plus dans ce cursus c'est déjà la structure
de l'organisation des cours. Déjà il y a
les vidéos qui vous permettent de suivre
les cours à la vitesse que vous souhaitez, revenir en arrière
mettre pause. Il y a également
les quizzes qui vous permettent de valider vos acquis
et il y a également les challenges
et les défis qui sont proposés
par les travaux pratiques qui sont associés
à chaque cours. Alors moi je le conseille vivement
ce cursus, déjà pour
toutes les personnes qui sont un petit peu familiales
à la démarche, ça ne peut que confirmer
certaines approches, ça peut vous apporter de nouvelles visions également.
Je le conseille aussi
à tous les curieux, tous les curieux
qui souhaitent apprendre, qui aiment apprendre,
qui aiment découvrir, ben là rien de mieux
et puis bien sûr je le conseille à tous
les réfractaires qui pensent que c'était mieux
avant et que bon ben je n'en parle pas
pourquoi je changerais ma manière de travailler, de coder.
Vraiment je le conseille à toutes les personnes
la démarche Craftmen c'est une super belle
manière de répondre aussi
à l'agilité Scrum de la manière technique
Donc quoi de mieux, allez-y
jetez vous dans l'aventure
vous n'en sortirez que grandis
et avec de nouvelles idées et de nouvelles pensées
Donc vraiment
allez-y vous ne regretterez pas.
Tu es encore là ? Mais qu'est-ce que tu attends pour Kiki ?