Actus

p.06 Côté livres...
p.08 Les dangers des systèmes legacy

Développement

p.18 La surcharge ou overloading en Python

Dossier : Spécial développeur, la boîte à outils indispensable !

p.24 Introduction au dossier
p.26 Utilisation de l’IDE Visual Studio Code
p.48 Property based testing et mutation testing system en Python
p.64 Analyse de code avec Cppcheck (et intégration sous Eclipse)
p.80 CrossDev sous Eclipse

Décryptage

p.98 Créez une extension pour LibreOffice

Bas niveau

p.114 Réinvention de la roue... des temporisations

« Congratulations {CUSTOMER_FIRSTNAME} {CUSTOMER_LASTNAME}, your friend has registered. »

Je sais, je me répète au fil des éditos, mais j’ai vraiment l’impression que la situation se détériore, que de plus en plus de développeurs n’effectuent pas la plus élémentaire des vérifications de code. J’ai donc répondu à ce mail. Voici la traduction :

« Il semblerait que vous ayez un bug dans votre template... CUSTOMER_FIRSTNAME et CUSTOMER_LASTNAME sont des gens de votre base de données et vous auriez dû vérifier la validité de votre message avant passage en production.

Bon debugging ! »

Quand on envoie un mail comme celui-ci, on se dit que l’on a fait son devoir en signalant le problème à une petite entreprise dont le système informatique ne doit pas être très au point. Et là, surprise ! Immédiatement après je reçois un mail automatique me signifiant la création de mon compte sur le gestionnaire de suivi des tickets et la transformation de mon mail en ticket. Ouah ! Tout n’est pas perdu ! Après avoir parcouru toute l’interface du gestionnaire de tickets, tout est expliqué clairement et utilisable aisément (un gestionnaire de tickets normal). Alors il est quand même étrange de trouver une erreur aussi naïve...

C’est alors que me revint l’histoire d’un autre bug, une faille de sécurité détectée sur un site et corrigée par un prestataire. Après avoir testé la modification, il s’avérait que la faille était bien colmatée, mais que le site était devenu beaucoup plus lent. Il avait alors été demandé au prestataire d’optimiser son code. Fin de l’histoire. Quelques mois plus tard, branle-bas de combat : il y a une faille dans le site ! En fait, l’optimisation du code avait réouvert la faille et, faisant confiance au prestataire, rien n’avait été testé. Comme lui-même se pensant bien meilleur que tout le monde n’avait pas besoin de tester son code, le bug avait survécu à sa correction initiale.

Ceci pose donc la question de la délégation de responsabilité : jusqu’à quel point peut-on faire confiance aux autres ? Et s’il existait un mécanisme permettant justement que tout le monde s’assure qu’il n’y ait pas de régression dans le code, que celui-ci fonctionne bien comme il le devrait ? Comment ? Ça existe déjà ? Et cela fait justement partie des thèmes traités dans le dossier de ce hors-série ? Eh bien bonne lecture alors ! :-)

Tristan Colombo