Archive

Articles taggués ‘clean code’

Atelier MUG Lyon – Test After/Before & TDD + Afterwork

C’est décidé pour ce mois-ci, au MUG-Lyon (association annuellement sponsorisée par VISEO), on organise un séminaire « Test After/Before & TDD » animé par Antoine Vernois, un spécialiste Clean-Code/TDD/BDD, que l’on fait venir en exclusivité de Toulouse.

Inscription gratuite : http://www.eventbrite.fr/e/billets-mug-lyon-test-afterbefore-tdd-afterwork-5224596910

C’est avec plaisir que vous y êtes conviés. Cette soirée sera suivie d’un apéro, histoire de discuter entre experts et passionnés.

Java, Node.JS, PHP ou Microsoft,… venez !! c’est techno-agnostique et axé sur des méthodo et Best Practices. Promis, on ne parlera donc pas de Microsoft, mais plutôt d’Agilité de TDD, BDD, CleanCode…

On aime, on partage #18

Bienvenue dans la série « On aime, on partage » d’Objet Direct !
Chaque semaine retrouvez les meilleurs articles du web issus de notre veille technologique.
 
 
 
 
 

Agilité

Jeu de culture

Excellent article d’Alexandre Boutin sur le mini livre de Daniel Mezick “Jeu de Culture”, traduit par Olivier Destrade (@OlivierDestrade).

Ce mini livre fait écho à un précédent “On aime on partage” sur la keynote de Rob Richman “Culture Hacking”, présenté lors du ScrumDay 2013. Dans ce mini-livre, vous trouverez des techniques sur le changement de culture.

Je vous invite à lire d’abord l’article d’Alexandre qui nous livre ses impressions sur la lecture de ce mini-livre, et qui vous donnera, assurément, l’envie d’entamer ce mini-livre.

 

Développement

How To Write Unmaintainable Code

Comment se garantir un travail à vie ? Simple, il faut suffit d’écrire du code rapidement impossible à maintenir et à faire évoluer. Plutôt difficile pensez vous ? Roedy Green va vous aider en vous donnant les meilleurs recettes dans votre aventure du job-protect. C’est amusant à lire mais aussi un peu vexant quand on s’aperçoit qu’on a déja rencontré de telles lignes de code. Ou pire, qu’on en a déjà écrites …

http://thc.org/root/phun/unmaintain.html

10 trucs infaillibles pour rater ses tests unitaires en toutes circonstances

Pour rester dans la même veine que l’article de Roedy Green, Bruno Doolaeghe nous explique comment être sûr d’écrire des tests unitaires qui rateront. C’est un article très didactique agrémenté d’exemples de code. Bruno ne se contente pas d’aligner des mauvais exemples. Il explique pourquoi ces tests sont mal conçus et donne des pistes pour améliorer la qualité  de ces tests. Là aussi, on est quelquefois un peu vexé de voir qu’on a pu committer ce genre de tests …

http://blog.soat.fr/2013/09/10-trucs-infaillibles-pour-rater-ses-tests-unitaires-en-toutes-circonstances-12/

 

Merci à nos contributeurs de la semaine : Benjamin MARRON et Jamel Ghechoua

On aime, on partage #3

Bienvenue dans la série « On aime, on partage » d’Objet Direct ! Chaque semaine retrouvez les meilleurs articles du web issues de notre veille technologique.

Java 8: Secure the train

Mark Reinhold, responsable du développement de Java SE chez Oracle, a annoncé la semaine dernière que la sortie Java serait repoussée au premier trimestre 2014. Initialement prévue pour septembre de cette année, il explique que ce choix est dû à une réorganisation des priorités. En effet, le plugin Java pour les navigateurs a beaucoup fait parler de lui ces derniers temps, à cause de failles de sécurité. Ils ont donc décidé de mettre l’accent sur la sécurité et de retarder de quelques mois la livraison de Java 8.


Sur le net, certains développeurs ont exprimé leur déception et se demandent s’il ne faudrait pas plutôt abandonner le support des technologies client (applets Java et Web Start). En effet, ces dernières sont les sources principales de failles de sécurité, tout en étant de moins en moins populaires et beaucoup moins utilisées que leur équivalent côté serveur.


L’annonce de Mark Reinhold : http://mreinhold.org/blog/secure-the-train

Commentaires de la communauté Java sur Twitter : https://twitter.com/mreinhold/status/325464368143794176

Sortie de jQuery 2.0

jQuery 2.0 est sorti ce 18 avril après 10 mois de développement. jQuery 2.0  ne supporte plus les versions 6,7 et 8 d’IE permettant ainsi de régler des problèmes d’incompatibilités et de performances. Deux branches distinctes sont donc développées actuellement:

  • une branche jQuery 1.X où les anciens navigateurs sont supportés

  • une branche jQuery 2.X

Vous trouverez plus de détails sur les changements apportés sur le blog de jQuery.

http://blog.jquery.com/2013/04/18/jquery-2-0-released/

Coding, Fast and Slow: Developers and the Psychology of Overconfidence

Dan Milstein, ingénieur chez Hut 8 Labs, se demande pourquoi sommes-nous si mauvais quand il s’agit d’estimer le coût de développement d’un logiciel.

Il met en avant deux causes : la première est que, pour pouvoir être précis, il faut avoir une connaissance totale de ce qu’il faut faire, et donc avoir des spécifications précises. Le problème est que, pour que ça marche, la spécification doit tellement être précise que cela revient à écrire le logiciel lui-même. L’autre source d’erreur est selon lui l’excès de confiance en soi, qui fait qu’un expert dans un domaine précis aura tendance à toujours croire à ses propres estimations, même si les échecs successifs lui montrent qu’il se trompe à chaque fois (voir aussi notre article sur l’art d’avoir tort).

En conclusion, il suggère que nous nous fassions à l’idée qu’il est impossible de faire des estimations précises sur plusieurs mois de travail, mais que nous pouvons contourner le problème grâce aux méthodes agiles. Il détaillera ce dernier point dans un prochain article.

http://blog.hut8labs.com/coding-fast-and-slow.html


What Makes Code Readable: Not What You Think

John Sonmez se propose de nous expliquer ce qui, selon lui, rend un code plus lisible. Dans un premier temps, il explique que ce qui est lisible pour un programmeur expérimenté l’est beaucoup moins pour un novice. Il prend comme exemple l’apprentissage de la lecture ou de la musique.

Il explique ensuite que plus une grammaire de langage est riche, plus il sera facile d’exprimer des concepts avancés de manière lisible et concise. La contrepartie sera un effort plus important pour maîtriser cette grammaire, ce qui peut faire le succès de langages plus simples donc plus facile à appréhender.

Il conclut que la lisibilité du code sera de plus en plus aisée au fur et à mesure que les lecteurs seront formés à ces langages.

http://java.dzone.com/articles/what-makes-code-readable-not

Merci à nos contributeurs de la semaine : Clément Plantier, Benoît Parmentier et Benjamin Marron