Traitement des demandes de modif

Samedi 17 septembre 2005 12:20 - Code

Il y a longtemps (trop), en développant différents logiciels, il y avait toujours bien un utilisateur pour envoyer un mail demandant tel ou tel changement mineur, genre «est-ce que l'email pourrait être affiché sous la forme "toto@example.com (Toto)" plutôt que sous la forme "Toto <toto@example.com>" ?». Puis un autre demandant une variation, genre «est-ce que l'email pourrait être affiché avec juste l'email, pas le nom de la personne?». Etc.

À l'époque, je voyais deux options. Oui. Et non. Ajouter l'option ou considérer que non, ça n'en valait pas la peine. Maintenant il y aurait une troisième option, qui serait avoir l'option mais ne pas l'exposer dans l'interface de configuration, et peut-être que cela serait souvent la décision adoptée.

Maintenant, une autre situation, c'est toujours du logiciel libre mais il y a un client, un client avec des sous, tout ça, à qui il est plus difficile de dire non, surtout quand des intermédiaires entrent en jeu, intermédiaires qui n'ont généralement aucune idée de ce qu'impliquera une demande particulière, qui iront au pif, se planteront parfois ou souvent, c'est selon.

Arrive ainsi la demande formulée (plus ou moins précisément, plutôt moins que plus), quelles sont les possibilités ?

1) Cette demande est tout à fait sensée, hop, adoptée pour tout le monde. Je n'ai pas l'impression que ça arrive souvent.

2) Cette demande est sensée, mais dans un contexte particulier, qui n'est pas le contexte général, mais d'autres demandes dans d'autres contextes pourront bénéficier d'une telle option. Il s'agit alors là d'ajouter une option de configuration.

3) La demande n'a aucun sens, même dans le contexte particulier, mais personne n'a dit non. C'est là que ça devient galère et technique; il faut dériver de la base logicielle vers autre chose.

3a) copier la base, puis taper dans cette copie. Jamais une solution car carrément galère à entretenir sur du long terme, les modifications générales devant également y être rapportées, etc.

3b) orientation objet, dériver, surcharger, tout ça. Ça ne marche pas toujours, ça peut nécessiter de grosses modifications dans le code d'origine pour permettre de modifier juste le point concerné. Alors soit on se retrouve à recopier beaucoup trop dans les classes qui dérivent, soit on se retrouve avec un trop plein d'appels dans la version de base, la majorité des appels n'étant en fait là uniquement pour permettre à la classe dérivée de s'insérer où elle en avait besoin.

3c) les solutions dégueux. Quand il n'y a rien d'autre à faire, que décidément, la demande est vraiment trop conne que pour être traitée autrement. Deux exemples:

  • le post-processing: ajouter un gros et bête filtre sur la fin de la requête, qui prendra le résultat, tapera dessus avec une regex à la con. Parfait pour les demandes du genre « il faut que l'identifiant de l'utilisateur soit son adresse email mais il faut que le label du champ reste identifiant ».
  • la perversion de gettext: gettext gérant les traductions, modifier la table de traductions pour avoir le résultat voulu par le client, même si ça n'a aucun rapport.