Archive
Deux, c’est bien, mais un, c’est mieux!
Un petit article sur un détail important mais qui, je crois, n’a pas été beaucoup discuté; le nombre d’appels sur des objets dans une ligne de code.
Prenons par exemple la ligne de code suivante, ou employe est un paramètre de méthode:
int assignements = employe.GetHoraire().GetAssigments(this.jourEnCours).Length;
Elle peut paraître exagérée pour certains, mais elle représente plusieurs cas que j’ai vu et que j’ai fait. Beaucoup auront prévu le coup; en production l’erreur suivante est lancée:
Object reference not set to an instance of an object.
Un éditeur de code semi-graphique
L’affichage des composites en ASP.NET
Beaucoup de gens ont travaillé avec des composites. Ils s’avèrent en effet utiles pour déterminer des règles imbriquées, des catégories à plusieurs niveaux, des menus récursifs etc. Il est par contre difficile de les afficher en ASP.NET sans transformer le code en amas monstrueux de conditions. Voici donc l’approche qui, selon mon humble opinion, s’est avérée la plus simple et la plus facile à maintenir. Read more…
L’importance d’une bonne vision
Il est impressionnant de voir à quel point la vision logistique d’un projet peut influencer l’efficacité du développement et la motivation d’une équipe. Malgré qu’on tente souvent de minimiser l’information concernant les besoins d’affaire concrets dans une analyse pré-digérée ( surtout dans une grande entreprise ), l’équipe, ayant les deux mains dans La réalisation d’une solution se trouve souvent devant des dilemmes non pas d’implémentation, mais de logique. Certaines demandes peuvent sembler ne faire aucun sens, ou même être issues de mauvaises décisions. Dans d’autre cas, certaines demandes sont contradictoires, et le développeur a le choix entre affronter les preneurs de décision, ou concocter une solution satisfaisant tout le monde, selon son propre avis. Le développeur faisant face à ces problèmes construit une certaine frustration, mêlée à un sentiment d’impuissance. Deux comportements font surface; une colère minant le moral général de l’équipe, ou un abandon: “Bof, tant que j’ai mon chèque de paye…”.
Les Navigation Nodes; une approche pour la navigation web
Dans tous les projets web que j’ai eu l’occasion de développer jusqu’ici, un chose est indiscutablement présente: un plan de navigation, spécifiant quelles pages mènent à quel endroit, dans quels contextes et conditions. Ces problèmes m’ont amené à développer (avec l’aide de Stéphane) et implémenter avec succès dans deux projets une méthode que je nommerai ici “Navigation Node”. Problème:
- La navigation est étroitement liée au design, donc difficile à maintenir
- Les changements de flux de navigation demandent beaucoup de tests et de vérifications
- Les URLs dynamiques sont souvent difficiles à gérer
- Il n’y a pas d’endroit centralisé ou gérer la logique de navigation
Le code; un simple format de spécifications?
(Cet article est un pot-pourri d’idées, qui sera probablement clarifié dans différents articles plus tard) Lors de nos nombreuses discussions errant entre la philosophie et l’interrogation technique, Stéphane et moi parlions souvent de notre conception du code et du développement logiciel en général. Certaines différences de point de vue mineures, telles que: “devrions-nous mettre des espaces entre la première parenthèse d’une méthode et son premier paramètre?”, nous ont vite fait remettre en question notre vision du code. Jusqu’ici, le code était le résultat, là ou tous les processus et l’analyse mènent. Désormais, il n’est à nos yeux qu’une vue pour l’interpréteur ou le compilateur, tout comme les fonctionnalités sont des explications au développeur ou les spécifications pour le client. La première idée issue de ce principe était de lier de manière forte les éléments des documents d’analyse à travers le code, ainsi qu’aux différents diagrammes. De cette manière, on pourrait facilement juxtaposer les différents éléments dans une vue propre aux besoin d’un rôle. On pourrait aussi aisément suivre les changements autant en amont qu’en aval. On rend donc la documentation manuelle inutile, en plus d’en fournir une exacte et à jour en tout temps, puisqu’elle implémente un ou plusieurs éléments des documents d’analyse. Cette idée serait principalement traduite par une application de collaboration impliquant une structure de contenu extrèmement rigide.