23 Ncrafts 2016 - Blog Nexeo
Conférence

Ncrafts 2016

18 mai 2016

Nous avons assisté les 12 et 13 mai 2016 à plusieurs sessions lors de la conférence NCraft (http://ncrafts.io/ ) qui parle notament du software craftsmanship et des différentes problématiques IT liées à l’architrecture logicielle.

 

Voici quelques unes des sessions qui valaient le détour :

The Long Road (http://ncrafts.io/speaker/sandromancuso)

Cette conférence en keynote se focalisait sur l’aspect gestion de carrière : quels sont les choix de carrière, comment sélectionner les entreprises qui nous conviendraient, notament à partir de ce que l’on peut apprendre des entretiens et du processus de sélection. En étudiant attentivement par exemple les annonces de poste d’une société, de nombreux éléments sont déjà interprétables tels que les versions des librairies utilisées. Les approximations faites et mêmes les points de suspension permettent d’identifier si l’entreprise s’intéresse vraiment aux technologies mentionnées. Lors des tests techniques, voir quel est le respect du travail fourni pour le code proposé.

Mais finalement monter en compétences, celà ne se fait pas par hasard, c’est beaucoup de sacrifices. Construire sa carrière n’est pas une tâche facile et surtout qui saura quelle sera la techno la plus populaire dans quelques années : les missions ne constituent pas une carrière, il est juste plus difficile de changer d’orientation si l’on est resté vraiment longtemps dans une direction donnée. Néanmoins chaque mission est un investissement.

No estimates: how you can predict the release date of your project without estimating (http://ncrafts.io/speaker/duarte_vasco#nc16-vdu01)

Vasco Duarte a indiqué que son livre électronique est disponible gratuitement en téléchargement via l’url http://j.mp/NoEstimates-time-limited-promo

La question que Vasco a mis en avant est la suivante : « qu’est-ce qui vous empêche de livrer demain? », afin d’identifier les dépendances. L’idée est de livrer quotidiennement pour collecter du feedback dès que possible. Si l’on cherche a quantifier la charge de développement il faut se rappeler qu’une user story peut facilement doubler ! Plutot que de quantifier en story point , l’estimation est bien meilleure lorsque l’on se base sur le nombre de stories : ainsi sur 50 sprints on constatait que l’estimation basée sur les story points n’était à aucun moment meilleure à celle basée sur le nombre de stories.

The Art of Visualising Software Architecture (http://ncrafts.io/speaker/simonbrown)

Nous pouvons souvent visualiser des processus mais pas l’architecture visuelle de nos propres logiciels. Il existe de nombreux logiciels de génération de diagrammes sur le web utilisables en ligne, mais ce sont des outils pour un but général.Le problème de beaucoup d’outils c’est qu’ils présentent le code et pas un regroupement par composant  : il manque un regroupement sur les composants significatifs d’un point de vue architecture

Il faudrait des cartes pour lesquelles on puisse « zoomer » avec par exemple les niveaux suivants : non technique / technique / très technique

Le livre recommandé est « Just Enough Software Architecture » : just enough software architecture

 

 

Simon Browna mis à disposition plusieurs ebooks via le site leanpub.com dont notament celui-ci gratuitement: https://leanpub.com/visualising-software-architecture

visualizing softawre architecture

Il a développé un outil appelé Structurizr for .NET qui est disponible sur github ici : https://github.com/structurizr/dotnet (ce lien github propose un petit tutoriel de démarrage)

 

How to fail at code review in 5 lessons (http://ncrafts.io/speaker/mdomenjoud)

La revue de code est une pratique d’équipe pour obtenir du feedback. Elle permet notamment de partager entre tous des standards et de la compréhension. L’intérêt de la revue c’est de détecter des défauts le plus rapidement. Il existe 3 formats :

Pour détecter les défauts et favoriser l’échange, les bonnes pratiques sont les suivantes :

  1. Prévoir du temps
  2. Préparer la revue en lisant le code à l’avance, et en utilisant un checklist des éléments à vérifier
  3. Pas de revue sur plus de 300 lignes de code à la fois (1h30 au maximum)
  4. Avoir un moment d’échange pendant la revue
  5. Ce doit être l’auteur qui corrige les défauts afin qu’il apprenne de ses erreurs et progresse
  6. Se baser sur des standards de code , mais attention, la revue doit être consacrée à l’analyse du code pas à la revue des standards
  7. Critiquer le code, pas la personne !

 

Skills for good developpers (http://ncrafts.io/speaker/houssamfakih#nc16-hfa01)

Il est important de bien se connaitre via des métriques : pour cela Houssam recommande d’évaluer son niveau et de s’entrainer.Il existe par exemple des sites d’entrainement tels que exercism.io

Les impacts métiers positifs sont la vitesse et la qualité.

Il faut maitriser les basics (savoir bien les faire, et savoir les faire efficacement) et être consistant. La consistance s’obtient via la pratique régulière

 Il recommande de mesurer le temps que le développement nous prends.

Ajouter un commentaire


Votre commentaire sera modifié par le site si besoin.

À lire également

Les Web Services d’Amazon (Amazon Web Services), c’était le thème qu’abordait ce summit annuel : une panoplie…

Comme beaucoup, j’ai commencé le blue book d’Eric Evans sans jamais le finir… Je le trouvais trop…

Le 22-23 avril dernier, j’ai étais à mon premier Devoxx Paris, conférence généraliste dédiée aux développeurs. Depuis…