- un premier article au sujet du développement au forfait qui n'est pas compatible avec les besoins d'itérations des méthodes agiles (modification des spécifications).
- un article sur les problème de mesure de la qualité (et la non qualité) pour pouvoir réduire cette non qualité. Il faut des critères mesurés par des outils.
- Quatre gurus donnent leur point de vue sur la qualité du code.
- Premier chapitre du livre "Coder propement" : Introduction. La lecture de ce livre est fortement recommandé à tous ceux qui manipule du code.
- Un petit memo sur les 23 design patterns du Gang Of Four (GOF).
- Encore quelques articles au sujet du JDK 7 :
- Le JDK 7 en open sources
- le projet coins : fin des proposition d'évolution du langage
- le JDK 7 et les performances d'accès aux tableau et sur l'arithmétique
- le projet de modularisation du JDK
- Un article sur les enumérés dynamique.
Bonne lecture
Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait.
En matière de sous-traitance du développement logiciel, la pratique contractuelle la plus fréquente est celle dite du projet au forfait. La notion de forfait n'a, en principe, pas de rapport avec le processus de développement ou les pratiques d'ingénierie utilisée dans la réalisation du projet. Il s'agit simplement, dans l'esprit des contractants, de fixer les contours exacts de leur relation commerciale, et de définir leurs obligations mutuelles – en terme de coûts, de délais, de mode de paiement et de livraison.
Ce processus de développement est aujourd'hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l'impulsion des méthodes agiles. Je pense quant à moi que la "cascade" sera perçue dans quelques années comme l'aveuglement juvénile d'une industrie encore adolescente, à la recherche de son identité. La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade.
Mesurer la qualité d'un projet pour le désendetter
En ingénierie logicielle, tant qu'un projet se développe, la dette technique s'accumule inexorablement. Les sessions de refactoring sont là pour contrebalancer cette tendance et leur mise en place régulière garantit la maintenabilité du projet. Mais ce qui est délicat avec la dette technique, c'est qu'elle n'est pas vraiment mesurable, et comme l'iceberg, on n'en voit que la partie émergée. Résultat, le refactoring est souvent sous estimé et mal maitrisé. Si on ajoute à cela une mauvaise couverture de test, refondre le code applicatif fait peur, fait mal.
Plus personne n'a l'audace de le tenter, et à long terme, c'est la banqueroute assurée du projet.
L'objectif de cet article est de proposer une approche efficace pour savoir comment attaquer efficacement un grosse refonte d'un code mal couvert par les tests. Cette tâche technique est divisée en plusieurs problématiques : comment déterminer les zones de risque du projet, trouver où poser les tests pour sécuriser l'étape de refactoring et trouver les zones à refactorer.
The Developer Insight Series, Part 1: Write Dumb Code -- Advice From Four Leading Java Developers
Most performance problems these days are consequences of architecture, not coding -- making too many database calls or serializing everything to XML back and forth a million times.
While we write code to run on a machine, the primary consumers of code are humans.
Coder proprement
La maîtrise de l'art du métier englobe deux parties : connaissances et travail. Vous devez acquérir les connaissances concernant les principes, les motifs, les pratiques et les heuristiques connus de l'artisan, et vous devez également polir ces connaissances avec vos doigts, vos yeux et vos tripes, en travaillant dur et en pratiquant.
Je peux vous enseigner la physique qui permet de rouler à vélo. Il est vrai que les mathématiques classiques sont relativement simples. Gravité, frottements, moment angulaire, centre d'inertie, etc. peuvent être expliqués en moins d'une page d'équations. Grâce à cette formule, je peux prouver qu'il vous est possible de rouler à vélo et vous apporter toutes les connaissances dont vous avez besoin pour ce faire. Néanmoins, vous tomberez immanquablement la première fois que vous grimperez sur la bicyclette.
Écrire du code n'est pas si différent. Nous pourrions rédiger tous les bons principes d'écriture d'un code propre et vous faire confiance pour réaliser le travail (autrement dit, vous laisser tomber lorsque vous monterez sur le vélo), mais quelle sorte de professeurs serions-nous alors et quelle sorte d'étudiant seriez-vous ?
Apprendre à écrire du code propre est un travail difficile. Cela ne se limite pas à connaître des principes et des motifs. Vous devez transpirer. Vous devez pratiquer et constater vos échecs. Vous devez regarder d'autres personnes pratiquer et échouer. Vous devez les voir hésiter et revenir sur leurs pas. Vous devez les voir se tourmenter sur des décisions et payer le prix de leurs mauvais choix.
ABOUT DESIGN PATTERNS
This Design Patterns refcard provides a quick reference to the original 23 Gang of Four design patterns, as listed in the book Design Patterns: Elements of Reusable Object-Oriented Software. Each pattern includes class diagrams, explanation, usage information, and a real world example.
Java 7: new coffee
Big changes
JVM changes
Project Coin
Conclusion
The biggest difference compared to previous Java releases is the fact that all development is done in the open. Most of it will be part of the OpenJDK project, and otherwise as part of the Java 7 project. The OpenJDK development release, which already contains some improvements for Java 7, can be downloaded and installed at this very moment. So check it out if you want to try the new features!
Project Coin: The Call for Proposals Phase is Over!
Project Coin's call for proposals phase is now over! Thirty four days long, the proposal period included nearly 70 proposals being sent to the mailing list, 19 coming in over the last two days, and over 1100 messages on the list discussing those proposals and related topics. With the flurry of pre-deadline activity over, the more deliberative task of finishing reviewing and evaluating the proposals awaits.
JDK 7 Twice as Fast* as JDK 6 for Arrays and Arithmetic
The 7th version of the Java Developer's Kit (aka JDK 7) delivers quite a speed boost over JDK 6 array accesses. For us, this is huge. It's like another year and a half of Moore's law for free.
Java's always suffered relative to C in straight matrix multiplication because Java does range checks on every array access (set or get). With some clever static and run-time analysis, Würthinger et al. are able to eliminate most of the array bounds checks.
Project Jigsaw
Vision The JDK is big—and hence it ought to be modularized. Doing so would enable significant improvements to the key performance metrics of download size, startup time, and memory footprint.
Java libraries and applications can also benefit from modularization. Truly modular Java components could leverage the performance-improvement techniques applicable to the JDK and also be easy to publish in the form of familiar native packages for many operating systems.
Finally, in order to realize the full potential of a modularized JDK and of modularized applications the Java Platform itself should also be modularized. This would allow applications to be installed with just those components of the JDK that they actually require. It would also enable the JDK to scale down to smaller devices, yet still offer conformance to specific Profiles of the Platform Specification. Okay—so where do we start?
Dynamic enums in Java
The introduction of Enums in Java 5 finally provided a powerful (and slightly magical) way of modelling fixed sets. One can have too much of a good thing, however, and in some situations an enum is a little too fixed to be convenient. Here, I'd like to discuss a pattern I'll call - for want of a better name - the dynamic enum, that addresses this issue.
"'Dynamic enums'? Isn't that a bit like 'type-safe scripting language' or 'fully-specified requirements'?" Well, let me try to outline the intended purpose of a dynamic enum:
