Le blog de Richard Carlier, Concepteur / réalisateur de sites Internet, Formateur, Créateur d'applications mobiles…
Le blog de Richard Carlier, Concepteur / réalisateur de sites Internet, Formateur, Créateur d'applications mobiles…
Attention: cet article date du 14 février 2012
Ce qu'il contient est peut être encore valable...
... ou complètement obsolète!
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.
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é.
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.
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…) :
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 :
Tant que l’on y est, je dédie celle-ci à mes élèves:
Encore faut-il que la documentation existe…
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).
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…
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.
Sans avoir de formule percutante, il est utile de connaître également certains principes ou méthodes…
Il y en a surement d’autres, n’hésitez pas à compléter en commentaire…
Sans surprise, la plupart de ces concepts ne sont pas limités aux développements logiciels.
En version Saint Valentin, nous pourrions avoir :
Ok, je sors…
Hé hé, thanks DevMaster !
Maintenant, en plus des formules, il faut se rappeler des sigles… Je dirai YAGNI Modulo !