Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je vais répondre à une question d'auditeur.
Bonjour Benoît, je travaille dans l'architecture d'entreprise
et dans mon boulot je développe ou organise des équipes de développement
dans l'objectif de livrer des paramétrages et ou des développements spécifiques
pour des projiciels propriétaires.
A titre personnel, j'accorde beaucoup de valeur au principe fondamental de l'agilité
et je découvre avec beaucoup d'intérêt la notion de craftmanship.
Ma question est simple, comment appliquer ces pratiques dans un contexte
où le développement n'est perçu que comme un accessoire
ou un outil palliatif est temporaire en attendant que le standard le fasse
et plus généralement que peut-on prendre de la philosophie craftmanship
lorsqu'on est intégrateur indépendant.
D'abord, je dois reconnaître une chose, c'est que je...
pas forcément une expérience énorme de ces sujets-là
et je te dis pourquoi à la fin.
Mais ce qui me semble déjà évident en première instance
c'est que dans la philosophie du craftmanship
ce qu'on peut prendre c'est l'amour du travail bien fait
et ça, quel que soit ce qu'on fait, je pense que ça reste valable.
Après, c'est clair que quand on est intégrateur,
qu'on configure des projiciels préexistants
on va toujours préférer de la configuration sur du développement
parce que ça coûte moins cher mais c'est aussi plus facile à maintenir
sinon les montées de versions coûte une blinde à chaque fois
et du coup on n'est plus tellement dans l'écriture de code
on n'est plus dans la conception, on est plutôt dans le paramétrage
dans la configuration.
Du coup, c'est vrai que si tu ne déffes pas la relation au code
par définition elle est différente.
Maintenant, si tu déffes des extensions
parce que comme tu le dis il y a des moments où le standard ne le fait pas
si tu déffes des extensions je pense que tu peux tout à fait appliquer
les principes du craft avec conception simple
avec le TDD, avec l'intégration continue, le binommage.
Tu vois, la première chose que je ferais moi
si je devais travailler sur un frère mort comme ça, un projiciel
je regarderais ce qu'il y a une bibliothèque de tests qui existent.
Par exemple, j'ai travaillé récemment avec une équipe qui bosse sur Salesforce
qui est un énorme projiciel que tu peux configurer,
que tu peux paramétrer et sur lequel tu peux développer
ils ont même leur propre langage.
Oui, tu as une bibliothèque de tests
tu peux travailler du coup on t'a aidé.
Je trouve ça assez intéressant à regarder.
Probablement que j'essaierais de faire des tests fonctionnels
donc si typiquement dans le cas d'un Salesforce avec une application web
je pense que j'essaierais de faire des tests fonctionnels avec du cucumber par exemple.
Bien sûr, tu peux aussi mettre en oeuvre des choses comme le binommage
c'est sûr si tu as indépendance et plus compliqué.
Et puis encore une fois je reviendrai sur cette question là
de l'intégration continue pour voir d'une manière générale
quelle est la toute la partie que je peux automatiser de ma toolchain.
Après, honnêtement, je te le disais en début,
j'ai peu d'expérience sur cette question
et c'est bon, une raison très simple.
C'est que j'ai toujours préféré le code
et je me suis rapidement éloigné de ce type d'outil
qui amène plus à de la confé et à du support
en fait que réellement du développement.
Tu vois par exemple quand j'ai la possibilité d'avoir un outil graphique
qui te permet de câbler des choses
je vais plutôt préférer le pendant code de cette même chose là
s'il y a une action que je peux faire en code
ou une action que je peux faire bien un outil graphique
je vais généralement privilégier l'option code.
Après, ce que je dois reconnaître aussi c'est que
je ne voudrais pas que ce soit mal compris comme quelque chose de...
mais en tout cas je reconnais que ça a d'autres valeurs ce marché-là
puisque tu es sur un marché qui est très différent
avec beaucoup plus de clients
parce que tu as plus de clients pour des solutions standards
que des solutions customes
donc tu as un marché qui est plus gros
et puis tu peux fidéliser tes clients
souvent ce type de prestations va avec des contrats de maintenance
ce qui génère du récurrent
là où nous on travaille essentiellement avec des startups
et start-up statistiquement, il y a 90% de casques
donc sur le plan business, cela me semble être un choix très intelligent
après sur le plan tech, c'est à toi de savoir ce que tu aimes faire
c'est vrai que comme ça m'attire moins personnellement
je vais moins te caler
mais je reste convaincu qu'il y a des choses à prendre
je te dis encore une fois, regarde si tu as une bibliothèque de tests unitaire qui existe
ça sera déjà un bon point de départ
et puis regarde ce que tu peux faire en termes d'automatisation
de ton workflow, de tes déploiements
de ta phase de qualification et de validation
voilà, j'espère que ça t'apportera un élément de réponse
et quand t'as toi, cher auditeur, qui n'a pas encore posé de questions
c'est très facile pour me poser une question
tu m'envoies un email benoîtarobaseartisandeveloper.fr
et puis je te réponds, c'est simple, c'est facile, c'est direct
je te dis à demain