Catégorie : bonne pratique

Tests vs tdd

Bonjour,

Aujourd’hui j’aimerais m’entretenir sur l’importance des tests unitaires, d’intégration, de charge et autres.

Il est très important d’effectuer des tests.

Faire du TDD ou écrire les tests après coup importe peu. Je pense que faire des tests sur les getters et setters devient un fardeau plus qu’une aide.

Certains setters ne sont pas triviaux, comme une conversion ou un casting. Dans ce cas, on peut avoir besoin d’en faire le test.

Ce qu’il ne faut pas faire, c’est réparer du code sans en écrire un test.

Une bonne pratique, plus que l’écriture des tests avant le code, a mon avis, est d’écrire un test avant la correction de bug.

C’est là que réside la puissance de l’automatisme. On remarque le comportement erroné du code. On écrit le test qui devrait passer au vert après correctif. Enfin, on écrit le patch qui fera passer le test.

Ainsi, on fait le plus important, des tests de non régression.

Faire attention à ses données

Introduction

Bonjour,

Aujourd’hui, on va parler des données. On n’est jamais trop paranoïaque quand il s’agit de sauvegarder ses données.

Je ne vais pas imposer les mesures de certaines entreprises qui imposent 2 sauvegardes éloignées de plus de 50km dans des coffres forts pour se pré-munir aux catastrophes genre incendie, tremblement de terre, vol industriel ou vandalisme.

Ici, je vais juste donner des petites astuces faciles à mettre en oeuvre, qui sauveront la vie un jour ou l’autre.

Clé usb

Les clés usb ne sont pas faites pour stocker les données. Elles sont faites pour transporter les données.

Il faut toujours avoir une copie de tout le contenu de sa clé ailleurs.

On ne travaille jamais directement sur le fichier depuis la clé usb. On fait une copie sur le bureau (ou dans mes documents), on effectue son travail, et ensuite on écrase la copie sur clé usb. Si l’ordinateur n’est pas à nous, on peut supprimer le fichier et vider la corbeille.

Si on a son travail dessus afin d’utiliser différentes machines, on désigne un des ordinateurs en tant que « responsable » de ce fichier. Dès que possible, on copie le fichier sur l’ordinateur responsable. Il se peut que sur la même clé on ait des fichiers qui ont des responsables différents.

Si on perd la clé usb, on sait ou trouver la dernière version des fichiers, et on aura perdu 1 journée max de travail.

Disque dur externe

Ne jamais attacher un disque externe en permanence sur son ordinateur. Si on a besoin de place, on en fait, ou on achète un disque dur interne plus gros.

Il est possible d’avoir en permanence un disque externe dans son cartable, mais il faut pouvoir se dispenser d’avoir à le brancher systématiquement.

Les films, musiques, téléchargements, photos seront délestés du disque principal et migreront vers le disque externe.

Un disque dur externe appel naturellement à la catastrophe avec son câble qui fait une si jolie opportunité pour le faire voltiger. Il faut faire attention à toujours le poser au milieu du bureau afin de ne pas avoir de boucle au bord de la table.

Alimentation

Il ne faut jamais bouger un disque sous tension (sauf SSD). Toujours poser son disque dur, ou laptop, avant de l’allumer. Et toujours attendre l’extinction avant de commencer à le ranger.

Sauvegarde

On peut sauvegarder toutes ses données sur le cloud, mais il y a toujours le risque que la société coule ou arrête le produit. Dans ce cas, on perd toutes nos données sans forcément de préavis ou trop court pour agir efficacement.

Il faut donc enregistrer ses données dans un disque dur local. De préférence que l’on ne bouge jamais (sur un vieil ordi qui joue le rôle de serveur de sauvegarde). Pas forcément allumé 24h/24, mais qui fait des sauvegardes au moins 1 fois par jour : on allume, on lance la sauvegarde, puis on éteint.

Régulièrement (une fois par semaine, par exemple), on branche un disque externe à notre serveur de sauvegarde pour récupérer l’intégralité de son contenu. Ce disque est dédié à la sauvegarde et ne bouge que pour aller de son tiroir de rangement, vers le serveur et y revenir le plus tôt possible. Ne pas laisser le disque dur externe attaché en permanence sur le serveur. Il suffirait d’un dysfonctionnement électrique pour griller les 2 seules sauvegardes locales.

Quoi sauvegarder ?

Il est inutile de sauvegarder des données que l’on peut récupérer facilement, comme la musique, les films, les logiciels téléchargés. Les bons candidats à la sauvegarde son les fichiers que l’on a créé soit même : Document office, photos et vidéos de vacance ou pro, codes sources (repository git par exemple), sauvegardes des jeux, etc.

Il ne faut pas hésiter à mettre tout le matériel électronique sous la sauvegarde. Ordinateur de bureau, ordinateur portable, téléphone, paramétrage du routeur etc.

Logiciel pour sauvegarder

Certains apareils ont un logiciel spécifique pour le tansfert, comme les smartphones, en revanche, ce qui est sur ordinateur peut être facilement mis à jour, grâce à des copies incrémentales (qui ne copie que ce qui à changé) via rsync ou cobian backup, pour ne citer qu’eux.

Conclusion

Il ne faut pas négliger la sauvegarde régulière de ses données et aussi vérifier de temps en temps que la sauvegarde automatique (si on opte pour celle ci) stock bien tous les fichiers.

Des petites habitudes évitent bien des déboires plus tard, ce n’est pas trop contraignant et comme dit plus haut, ça sauve la vie.

Les chemins vers les fichiers en php

Bonjour,

Voici un sujet qui me donne pas mal de soucis quand je veux faire une application web.

Comment écrire ses chemins ?

Il y a plusieurs façons de procéder et je vais donner mon avis sur chacune d’elles.

Contexte

Il faut d’abord savoir dans quel contexte on est. Le contexte dans ce cas est l’environnement qui va résoudre le chemin.

On peut distinguer 3 contextes différents :

Le contexte php : C’est PHP sur le serveur qui va résoudre le chemin et consommer le fichier.

Le contexte http de la page : C’est le navigateur qui va demander le fichier et il connaît l’url en cours.

Le contexte externe : On ne connaît rien sur l’adresse du fichier à atteindre. Quand on est dans un mail par exemple.

Invocation

Dans le contexte de PHP

On peut invoquer un fichier de plusieurs façons :

! J’ai choisis la commande include, mais toutes les autres invocations marchent de la même façon pour les autres types d’inclusion

Chemin aléatoire
include "../chemin/fichier.php";

C’est une inclusion relative au chemin courant.

Cette méthode marche mais on ne sais pas toujours quel fichier est utilisé à cause de sa méthode de résolution cf doc.

On se met à dupliquer les fichiers pour être sûr de l’inclure sans se prendre la tête à comprendre la résolution de PHP.

Chemin relatif
include __DIR__."/../chemin/fichier.php";

On donne ici le chemin absolu dans l’arborescence du serveur, mais dans notre tête, c’est un chemin relatif au fichier courant.

C’est la méthode que je privilégie car il devient simple de retrouver son chemin 🙂

Chemin absolu
define("_ROOT", __DIR__."/../cheminVersRoot");
include _ROOT."/cheminDepuisRoot/fichier.php";

! Les 2 lignes ci-dessus sont dans 2 fichiers différents, généralement config.php pour la 1ère.

Ici aussi on donne un chemin absolu sur le serveur à PHP, mais dans notre tête, on donne un chemin absolu depuis la racine du projet.

C’est une solution qui fonctionne bien et qui avait son avantage à l’époque où on avait l’url qui reflétait la structure des fichiers.

Dans le contexte HTTP de la page

Pour illustrer ce contexte, j’utiliserais une balise img (et sans les attributs obligatoires).

Chemin relatif
<img src="../chemin/fichier.png">

C’est un chemin relatif, ça marchait à l’époque où le fichier php avait le même chemin que l’url pour y accéder. Depuis la réécriture d’url, c’est une technique qui ne fonctionnera pas sans y laisser ses cheveux.

Chemin absolu
<img src="/chemin/fichier.png">

C’est la méthode que j’utilise, elle a l’avantage de donner un chemin absolu par rapport à la racine du projet.

Chemin externe
<img src="http://www.domaine.com/chemin/fichier.png">

Le travail et la maintenance deviennent un vrai casse tête, il faut être certain d’avoir modifié les chemins du serveur local avant l’envoi etc.

Chemin externe aidé par PHP
define("_HTTP_ROOT", "http://www.domaine.com");
ou (pire) define("_HTTP_ROOT", $_SERVER["HTTP_HOST"]);
<img src="<?= _HTTP_ROOT ?>/chemin/fichier.png">

! Les 2 lignes ci-dessus sont censées être dans 2 fichiers différents
! J’ai choisi HTTP_HOST mais SERVER_NAME marche tout aussi bien, mais il faut faire attention avec ces variables

On essaie de pallier au problème ci-dessus en n’ayant qu’une constante à modifier, mais il faut quand même penser à la modifier avant l’envoi.

Dans le contexte externe

La meilleure solution est le chemin externe décrit ci-dessus.

On peut néanmoins avec quelques précautions utiliser les variables dans $_SERVER.

Conclusion

Les chemins sont toujours un casse tête en PHP. Avec un peu de rigueur et en utilisant la bonne forme, on peut s’en sortir.

Je n’ai pas mis tous les dérivés de chemins que j’ai pu utiliser mais seulement un échantillon. Si vous avez une suggestion intéressante que j’aurais oublié n’hésitez pas à la mettre en commentaire.

Principe DTF (don’t fear typing)

Bonjour,

Aujourd’hui je vais parler d’une règle que je m’impose et que j’ai appelé DTF (don’t fear typing).

Copier-coller

Il y a beaucoup de cas où on est tenté d’utiliser le copier-coller. C’est une très mauvaise habitude et pratiquement tous les bugs viennent de là.

La tentation est très grande. On a un bloc qui fait presque le boulot ailleurs. Il suffit juste de le copier et de l’adapter.

Bien sûr, on le fait et on est sûr que tout c’est bien passé car il n’y avait que 4 occurence d’une variable à changer. On pousse directement en production.

C’est la catastrophe, le script marche une fois sur 2.

Si on est tenté de copier un bloc, il vaut mieux le retaper et se refaire l’algorithme dans sa tête au fur et à mesure de sa reconstruction. Investir un peu plus de temps en développement, c’est éviter d’en perdre en débogage.

Commentaires

Un autre cas de DTF arrive quand il faut commenter une section. On ne prend pas la peine de décrire le fonctionnement. Quelques jours plus tard, on ne peut plus modifier ce code car on ne se souvient plus de son fonctionnement et qu’il est trop compliqué pour s’en refaire une idée en simple lecture.

Quelques commentaires qui décrivent l’idée générale d’une fonction peut aider à la maintenance du code.

Attention, la pire chose que de ne pas commenter c’est d’avoir un commentaire faux.
Il faut maintenir les commentaires. Quand on modifie le code, on met à jour le commentaire !

Nommage

Le nom des fonctions et des variables n’ont pas de limite restrictive. On peut donc avoir des fonction de plus de 30 caractères. Si toutes les fonctions et variables ont un nom à rallonge, ça ne va pas aider à la lisibilité. Cependant, mettre que des noms courts n’aide pas non plus.

Il faut viser le juste milieu en ayant une combinaison de 3 mots tout au plus qui définissent au mieux la fonction ou la variable.

Il ne faut pas avoir peur de transgresser la règle pour avoir une meilleure lisibilité. On peut très bien avoir une boucle très courte avec « i » comme variable d’itération.

Conclusion

Il ne faut pas avoir peur du clavier, taper quelques caractères en plus peut faire gagner beaucoup de temps dans le long terme. Commenter quand c’est nécessaire, choisir le nom de ses fonctions et variables et ne jamais copier-coller.