Styles

vendredi 30 octobre 2009

Quelle est votre opinion la plus controversée sur la programmation ?

Je me baladais l’autre jour sur stackoverflow.com, le site de questions/réponses de Jeff Atwood que tout le monde attendait (vu le nombre de questions et réponses déjà présentes sur le site). Il y a toujours des questions qui cherchent à polémiquer, à créer des controverses, à relancer des guerres maintes fois débattues (la guerre des éditeurs, des OS…).

Je suis tombé par hasard sur cette question : Quelle est votre opinion la plus controversée sur la programmation ? Autant dire que ça doit inspirer pas mal de monde… et en effet, des pages et des pages d’opinions les plus diverses sont reliées à cette question.

Plusieurs opinions m’ont paru intéressantes, voici traduit en français celles de la première page, donc celles les plus intéressantes, puisque c’est l’objectif de stackoverflow.com de faire remonter le plus en haut les meilleures réponses aux questions :

  • La seule “bonne pratique” que vous devez utiliser tout le temps est “Utilisez votre cerveau”.
  • Les programmeurs qui ne codent pas pendant leur temps libre pour s’amuser ne deviendront jamais aussi bon que ceux qui le font.
  • La plupart des commentaires dans le code sont en fait une forme pernicieuse de duplication de code.
  • Les programmeurs ne sont pas tous nés égaux.
  • XML est très surfait.
  • “Trouver sur google” (googling) est bien.
  • Je n’arrive pas à comprendre pourquoi les gens pensent que Java est absolument le meilleur langage de programmation à enseigner en université
  • Si vous ne connaissez qu’un seul langage, quel que soit le niveau de connaissance de celui-ci, vous n’êtes pas un bon programmeur
  • La performance compte.
  • Les instructions “print” sont une manière valide de débugguer du code.
  • Les “Getters” et les “Setters” sont bien trop utilisés
  • SQL est du code. Traîtez-le comme tel.
  • Votre travail est de vous mettre au chômage.
  • Si vous êtes un développeur, vous devez être capable d’écrire du code.
  • La lisibilité est la chose la plus importante de votre code
  • Les diagrammes UML sont très surfaits.
  • L’utilisation de la notation hongroise doit être punie par la mort
  • Les modèles de conception font plus de mal à une bonne conception qu’ils ne l’aident effectivement.
  • Les tests unitaires ne vous aideront pas à écrire du bon code.
  • Ecrivez des méthodes courtes.
  • C’est acceptable d’écrire du code jetable de temps en temps.
  • Moins de code est mieux que plus de code.
  • PHP craint ;-)
  • Code == Conception
  • Il n’y a rien de mal à mettre des binaires dans le système de contrôle de code source.
  • Le développement logiciel n’est qu’un job.
  • Chaque développeur doit être familiarisé avec l’architecture des ordinateurs modernes
  • Les architectes / concepteurs de logiciels sont très surfaits.
  • Il n’y a pas d’approche « taille unique pour tout le monde » du développement.
Et ce n’est que la première page ! C’est du même acabit pendant 13 pages. On peut noter les autres opinions suivantes qui ont le mérite de provoquer aussi la controverse et force à réfléchir sur la futilité ou l’utilité de nos pratiques au jour le jour :
  • La plupart des programmeurs professionnels craignent un max.
  • Vous devez savoir taper à la machine pour être un programmeur
  • C++ est l’un des pires langages de programmation jamais conçu
  • Le monde a besoin de plus de GOTOs
  • Les architectes qui ne codent pas sont inutiles
  • Les programmeurs qui passent leur journée à répondre à des questions sur Stackoverflow ne font probablement pas le travail pour lequel ils sont payés.
  • Les mauvais programmeurs sont Langage-Agnostiques
  • Les utilisateurs ne sont pas idiots, vous l’êtes.
  • La documentation générée est presque tout le temps totalement inutile
  • Vous n’avez pas toujours besoin d’une base de données
  • Chaque développeur doit passer plusieurs semaines, voire des mois, à développer des systèmes sur papier avant de commencer à construire des systèmes sur électronique. Ils doivent aussi être forcés à utiliser leur système.
Tout cela est un méli-mélo de sagesse populaire, d’opinions tout faites, l’intérêt étant que tout porte à controverse, ça permet de se confronter à ce que ressent profondément notre profession (pour certains) ou notre « art » (pour les autres).

mardi 13 octobre 2009

Bases de données temporelles

Quand il s'agit de gérer des périodes de temps, SQL n'est pas très bien pourvu, et le modèle relationnel classique ne s'y prête pas naturellement. Sans essayer de passer par du TSQL2 et de s'attacher une technologie que finalement peu de monde utilise (l’utilisez-vous ?, je ne l’ai jamais vu en pratique sur des applications d'entreprise), on peut, avec malice, trouver des solutions pour représenter les différents états dans le temps d'un fait.

Tout est affaire de point de vue. Si vous avez une application tournant au dessus d’un modèle relationnel, il n’est pas nécessaire de modifier le code de celle-ci pour permettre l’historisation automatique des données manipulées.

Il n’y a qu’à remplacer les tables à historiser par des vues :
  • la vue a exactement les mêmes colonnes que la table qu’elle remplace
  • la vue est construite au dessus d’une table d’historisation contenant les mêmes colonnes qu’initialement, plus 2 nouvelles colonnes :
- DEBUT
- FIN
  • [DEBUT;FIN[ correspond à l’interval de temps pendant lequel l’entité a la même valeur (dans ses autres colonnes) (attention : DEBUT est inclus, FIN est exclu)
On peut vouloir stocker le temps-valide ou le temps transaction :

* Le temps-valide (ou « temps logique ») dénote la période de temps durant laquelle un fait est vrai par rapport avec la réalité.

* Le temps-transaction (ou « temps physique ») est la période de temps pendant laquelle un fait est stocké dans la base de données.

* La donnée bitemporelle combine à la fois le temps-valide et le temps-transaction.

A noter que ces deux périodes de temps n'ont pas à être égales pour un fait unique. Imaginez que nous ayons une base de données temporelle stockant des données relatives au 18ème siècle. Le temps-valide de ces faits se situe quelque part entre 1701 et 1800, tandis que le temps transaction débute quand on insère le fait dans la base de données, par exemple le 21 janvier 1998.

L’objectif est de pouvoir consulter la base de données à un instant T. Pour cela, il faut faire attention d’historiser aussi les données dépendantes par contrainte.

Les bases temporelles permettent souvent de différencier les programmeurs sur framework des programmeurs sur base de données. Un programmeur sur base de données va implémenter une base de données temporelle avec des vues et des triggers, offrant une vue propre des données à un instant T. Le programmeur sur framework va implémenter les règles de gestion du temps en Java au lieu d’utiliser des triggers et des vues et va aboutir, avec une grande probabilité, à une machine à gaz inmaintenable au bout de 3 mois.

Les vues et les triggers des bases de données sont des outils puissants et naturels pour implémenter :
  • le contrôle d’accès fin aux données,
  • l’historisation des données sous la forme de base de données temporelle.
Il est vain d’essayer de reproduire ces fonctionnalités au niveau de la couche applicative. Bizarrement, la mise en place de base de données temporelle est rarement évoquée sur asktom.oracle.com

Pour info, j'ai traduit la page Temporal database (Base de données temporelle) dans Wikipedia, histoire de combler à mon humble mesure le vide sidéral des articles informatiques en Français.

Pour en savoir plus sur les bases de données temporelle, autant consulter la liste de liens de Troels ou encore cette Introduction aux bases de données temporelles.