Passionné par le code et le travail bien fait, Johan en tant que développeur montre par l’exemple comment produire du bon code et livrer de manière fiable, dans une harmonie totale avec le métier. Il a une attirance non négligeable pour les problèmes concrets du quotidien, c’est sans doute pourquoi il s’intéresse tant au legacy.
Talks
Développeurs anonymes
Démo de refactoring. Introduire de l’objet efficacement dans un legacy infame.
La pyramide des tests - d'oú sort il?
Mike Cohn a dit qu’il fallait beacoup de tests bas niveau et peu de tests haut niveau. Quand est-ce que c’est vrai? Quand dois-je penser à apprendre à faire des tests ‘unitaires’ pour ne pas écrouler ma productivité avec une maintenance lourde des tests haut niveau? Une analyse basé sur deux expéreinces diamétralement opposées.
La valeur du bon code pour les non-devs
La valeur métier du bon code est difficile à appréhender, même parfois pour les développeurs. Comment pouvons-nous espérer qu’on nous demande d’en faire? Dans ce démo je rend compréhensible aux non techniques la valeur que leur apporte un code en bon état. Dans ce démo il parait aussi comme une évidence que pour passer d’un mauvaise état à un bon état il n’est pas tellement une question d’allouer du temps sur le moment, mais d’avoir de l’entrainement.
Refactorer legacy - même pas peur
Pour refactorer du legacy on aimerait avoir des tests, mais ils sont tellement difficiles/longs à écrire. De plus on a choix cornélien entre tests haut niveau avec un feedback lent et les tests unitaires qui vont trop adhérer au code et ne pas permettre certains refactorings. Une alternative est d’écrire des tets temporaires taillés pour le refactoring. Le fait qu’ils soient temporaires rend l’écriture extremement rapide…. Pas de Hello World, la démo se fera sur un exemple avec plusieurs dépendances non testables. Du vrai quoi!