Embrassez les secs…

Tiens, c’est la Saint Valentin? Oui, mais aucun rapport… Il s’agit ici d’une tentative (in)utile de recenser quelques formules à garder à l’esprit quand on aborde la programmation, quelque soit le langage, et qui peuvent faire gagner du temps…

Alors, parlons de KISS, DRY, RTFM, WTFM et autres YAGNI !

Attention, le mot fucking apparaît à plusieurs reprise dans cet article. Je m’en excuse à l’avance, mais il fait partie à part entière de certaines des expressions, le remplacer par un f***ing comme on le voit parfois ne me parait pas pertinent.

KISS, Keep It Simple, Stupid

La formulation choc de l’adage Pourquoi faire compliqué quand on peut faire simple ?

Simple signifie court. Il est plus simple de décomposer un problème en petits modules indépendants, chacun résolvant une petite part de la problématique globale. Vous aurez alors une batterie de fonctions dont l’usage sera… simple.  Mais simple ne signifie pas court. Le code est souvent plus long lorsqu’il est décomposé en de nombreuses petites parties.

Simple signifie explicite. Dans vos noms de variables, de fonctions, d’identifiants, de classes, de noms de fichiers… Souvenez-vous que, la plupart du temps, le code reste à sa place, ce n’est que l’exécution du code qui importe. Et donc le code peut être long dans ses noms si la clarté y gagne.

Simple signifie aussi lisible. Pour un oeil humain s’entend.

Illustrons un brin; que dire de ceci ?

for ($i = 1; $i<=13; $i++) { if ($i%2==0) { a($i); } else { b($i); } c(); }

face à

for ($compteur = 1; $compteur<=13; $compteur++) {
    if ($compteur%2==0) {
        traceLignePaire($compteur);
    } else {
        traceLigneImpaire($compteur);
    }
    specialeDedicacePourLeRoiDuModuloQuiMeLitPeutEtre()
}

On y applique des principes de bon nommage des variables et fonctions, et d’indentation (bref, de code lisible). Certains se reconnaîtront peut-être dans la dédicace?

Dans certains cas, la taille peut être importante (je ne parle toujours pas de Saint Valentin…). Par exemple, en Javascript, en CSS où le code est transmis au navigateur, avec utilisation de bande passante, donc de lenteur. Il reste souvent préférable d’être explicite, mais légèrement plus concis. Notre exemple devenant par exemple:

for ($i= 1; $i<=13; $i++) {
    if ($i%2==0) {
        paire($i);
    } else {
        impaire($i);
    }
    moduloManiac()
}

Qui plus est, pour le Javascript, il existe des outils qui vont le compacter/compresser (mais conservez la version d’origine!), jQuery illustrant bien ce principe. La version de production fait 31kb, mais la version humainement lisible (dite de development) en fait 229kb, les deux faisant la même chose!

Précisons pour les puristes que KISS s’apparente souvent à YAGNI (voir ci dessous), dans le sens faire au plus simple c’est à dire ne rajoute pas ce qui n’est pas demandé.

DRY, Don’t Repeat Yourself

La formulation choc de l’adage Ne pas réinventer la roue

Grand principe: dès qu’un bout de code peut servir plusieurs fois, raisonnez fonctions, objets, inclusion… Et car vous avez déjà fait un projet, vous pouvez recycler vos bibliothèques de fonctions d’un projet à l’autre. Certaines de mes fonctions me servent depuis des années…

Ce principe est clairement illustré par les Getters et Setters en Java (principe applicable en PHP et autres) seules fonctions aptes à accéder aux données, vous garantissant que tous les accès aux dites données seront toujours correctement effectuées, et toujours de la même façon.

Mais cela s’adapte aussi pour le WebDesign, comme par exemple une seule CSS pour tout le site, pour éviter de dupliquer des déclarations d’une CSS à l’autre (et si un truc change sur l’ensemble du site il faut les modifier toutes?).

CCM ? Gardons à l’esprit que le copier/coller est l’ennemi du programme (même s’il peut servir parfois, à condition d’ajouter le troisième mot clef, copier/coller/modifier).

On pourrait également ajouter un DRO (Don’t Repeat Others), vous incitant à chercher si quelqu’un sur Internet n’a pas publié un bout de code qui répond à votre problématique et qui vous éviterait de le refaire. Mais attention à ce que vous pouvez trouver… qui nous ramène à la règle précédente du CCM.

RTFM, Read The Fucking Manual

La formulation choc de l’adage La réponse ne serait-elle pas dans la documentation?

Cela m’est encore arrivé il y a quelques minutes (et un peu à l’origine de ce billet). Je cherchais une fonctionnalité pour une petite animation sous Android. Depuis plusieurs jours. De nombreuses heures de recherche, de découverte de blogs avec des extraits de code (souvent intéressants à lire, certes). Mais d’extraits de code qui ne fonctionnaient pas (toujours plus longs à tester). J’ignorais que l’on pouvait faire planter le simulateur, je le sais désormais (mais je m’égare). Bref, j’ai fini par mettre de côté pour passer à autre chose, qui me mène à la documentation officielle. Et je repense à mon animation, et me dis, et tiens, si… Et j’ai trouvé ce que je cherchais en 30 secondes (qui fonctionne en plus).

Bien sûr, cela ne marche pas à tous les coups. Mais souvent. Donc, toujours garder à l’esprit que lorsque l’on développe dans un langage précis, on garde la documentation à portée de main, doc que l’on a déjà parcouru et dont on sait se servir.

C’est assez facile de nos jours avec Internet et autres navigateurs. Les sites de documentations disposent souvent de moteurs de recherche, vos navigateurs disposent de favoris… Pour mémoire (et à ajuster selon vos intérêts du moment…) :

• Codex WordPress
• Developper’s Guide Android
• IOS Developer Library
• jQuery
• MySQL
• Php.net

En se souvenant que les versions anglaises sont souvent les plus pertinentes et complètes (quand les autres langues existent)

Citons pour s’amuser jusqu’au bout quelques expressions apparentées au principe fondamental du RTFM telles que :

• GIYF Google is your friend. Google est votre ami… en tapant toujours le nom du langage dans la requête, en premier…
• RTFSC Read The Fucking Source Code. Lisez les sources (voir WTFC ci dessous)…

Tant que l’on y est, je dédie celle-ci à mes élèves:

• RTFQ Read The Fucking Question… que l’on vous répète depuis l’école primaire
• RTFS Read The Fucking Specification… lire le cahier des charges qui procède de la même logique (voir YAGNI ci dessous).

Encore faut-il que la documentation existe…

WTFM, Write the fucking manual

La formulation choc de l’adage Ne faudrait-il pas une documentation?

Ben oui… il n’y a pas de manuel écrit sans écrire le manuel. Logique. C’est la force de certain logiciels (dont les open sources), et parfois une grande partie de leur succès.

Bien sûr, si on est dans le cadre d’une prestation, le client sera demandeur de la documentation de ce que vous lui faites (l’utilisation d’une interface d’administration par exemple). Et en tant que prestataire, prévoyez de lui vendre la rédaction de ce manuel. Car cela peut prendre beaucoup de temps a rédiger.

Petite touche de nostalgie: un de mes premiers stage était justement la rédaction du manuel de documentation d’un logiciel…

Et quand on parle de manuel, on parle autant de la documentation utilisateur (pour le client) que de la documentation technique (pour les développeurs).

WTFC, Write the fucking comments

Bon, c’est le même que le précédent, que je viens d’inventer (ah oui?).

En un usage plus personnel, il est utile (indispensable) de documenter son propre code en utilisant ce que l’on appelle des commentaires.

Toujours se souvenir que vous écrivez le code pour l’ordinateur, mais c’est un être humain qui le lit. Vous, le plus souvent. Oui, mais vous savez ce que vous venez de faire, non? Sauf qu’un projet Internet (ou autre) peut être long et modifier un code écrit il y a plus de 5 ans sans y passer des siècles est à la fois fréquent et  pas si simple.

Même à courte échéance, il suffit (cas fréquent) que vous travailliez sur plusieurs projets en parallèle…

YAGNI, You Aren’t Gonna Need It

La formulation choc de l’adage S’en tenir au cahier des charges

Ne faire que ce qui est utile, nécessaire, prévu, planifié, payé.

Anticiper les choses est une bonne chose, mais jusqu’à un certain point. Prévoir que l’application peut évoluer, oui, mais passer du temps à écrire des fonctions dans l’hypothèse où est une perte de temps. Surtout si vous êtes facturé au forfait (mais si vous êtes facturé à l’heure, c’est une sorte d’arnaque, non?).

S’il manque des fonctionnalités à faire évoluer, les V2 sont faites pour ça.

Autres points à garder en tête…

Sans avoir de formule percutante, il est utile de connaître également certains principes ou méthodes…

• TDD, Test-driven Development. développement piloté par les tests. En gros, on écrit une batterie de tests avant de réaliser le code, ce qui permet de savoir où l’on peut aller. Sans être totalement piloté par les tests, on se souvient qu’il faut tester un programme (et que faire des tests prends du temps, donc doit être inclus dans la facturation, si, si)
• FTTC, first think, then code. Ne pas coder avant d’avoir analysé le problème. Lire le cahier des charges n’est pas suffisant, il faut le comprendre, et un des meilleurs moyen est de l’annoter. Sur papier. Avec un stylo. 4 couleurs si possible.
• PEBCAK, Problem Exists Between Chair And Keyboard, la réponse d’un développeur à un utilisateur. Qui signifie que c’est de la faute de l’utilisateur. Qui n’a, par exemple, pas lu le mode d’emploi.

Il y en a surement d’autres, n’hésitez pas à compléter en commentaire…

Conclusion

Sans surprise, la plupart de ces concepts ne sont pas limités aux développements logiciels.

En version Saint Valentin, nous pourrions avoir :

• KISS : j’ai rien compris…
• DRY : tu me l’as déjà dit!
• RTFM : pourtant, j’ai mis un post-it sur le frigo
• WTFM : fallait m’envoyer un SMS
• YAGNI : oui le repassage s’entasse, mais il y a encore une lessive qui tourne

Ok, je sors…