Il ne s'agit pas de faire du "beau code"
Citation:
Envoyé par
kilroyFR
Generalement les technos evoluent tellement vite que reecrire du code 'qui fonctionne' mais qui n'est pas 'beau' n'a que peu d'interet a part derouler des heures.
(...)
Apres c'est le propre du developpeur de toujours considérer que ce qu'ont fait les precédents etait moche, mal foutu et donc refaire une enieme fois a sa sauce.
On est tous passé par là c'est la maladie du developpeur.
(...)
(En ce qui me concerne, en tout cas) Il ne s'agit pas de faire du "beau code", mais de faire du code concis, lisible, intelligible et performant... d'autant qu'il y a des chances que la prochaine personne qui doive intervenir ultérieurement sur ce code soit moi-même (et si c'est quelqu'un d'autre, il me remerciera), et quand j'ai divisé le poids des pages d'un site par cinq au cours d'une refonte, ce n'étais pas pour "faire beau".
Bon, sans le web et sur des sites de petites dimensions, il est possible de repartir de zéro, ce n'est probablement pas le cas dans d'autres domaines où la base de code est trop importante.
Concernant les "caprices" ou les "obsessions" des développeurs, que plusieurs commentaires ont évoqué, je conseille la lecture de l'article The care and feeding of software engineers (or, why engineers are grumpy) ou de sa traduction française, Soin et alimentation des ingénieurs informatique (ou pourquoi les ingénieurs sont grincheux)
L'auteur y aborde le fait que les développeurs, qui sont des travailleurs hautement qualifiés, sont également des personnes créatives auxquelles on ne permet pas d'exprimer leur créativité et qu'on confine à des rôles d'exécutants, ce qui n'est pas une bonne chose, de surcroît si on les fait bosser sur du mauvais code.
IL semble dès lors normal que ces devs veuillent réintroduire de la créativité dans leur boulot... mais pas au bon endroit.
L'auteur propose donc de permettre aux devs d'exprimer leur créativité ailleurs que dans les projets de leur boite, dans des hack days, des hack weeks, du temps libre octroyé pour développer des projets persos, etc. etc.
Vous en pensez quoi ?
PS : Bon, comme je l'ai dit, moi, j'ai une (modeste) expérience dans l'inté web. Dans d'autres domaines, les contraintes sont sans doute différentes.
À propos de la lisibilité...
Citation:
Envoyé par
Pyramidev
L'échantillon était faible (6 personnes, si je me souviens bien), mais une moitié trouvait le premier code plus lisible, tandis que l'autre moitié trouvait le deuxième code plus lisible.
Donc la lisibilité est en partie subjective. Par contre, la première version est bien plus adaptée pour faire du réusinage de code.
La lisibilité est une question complexe. Tout d’abord, la définition en est souvent floue/circulaire (lisibilité : qualité de ce qui est lisible), et le sens du mot varie selon l’objet auquel le mot renvoie (la lisibilité d’une carte géographique n’est pas la lisibilité d’un texte), et les synonymes et mots de sens proche abondent : intelligibilité, lecturabilité, compréhensibilité, appréhensibilité, appréhendabilité (liste non exhaustive).
Il s’agit ici de textes ordinaires, et non de codes informatiques.
En gros, dans le design web et la mise en page, et en matière de textes, les spécialistes de la question distinguent deux aspects de la chose :
La lisibilité “physique”/“optique”/visuelle, qui repose sur des éléments physiques : dessin des caractères, taille des caractères, espacement des caractères, espacement des mots, hauteurs de ligne, longueur des lignes, nombre moyen de caractères par ligne, nombre moyen de lignes par paragraphes, contraste texte/fond, distance par rapport au support, luminosité du support, etc., etc.
L’intelligibilité/lecturabilité/compréhensibilité/appréhensibilité/appréhendabilité, etc. d’un texte, qui est la capacité d’un texte à être compris le plus aisément possible, ce qui dépend de la familiarité des mots, de leur brièveté, de la non-ambiguïté de leur sens dans un contexte donné, de la syntaxe des phrases, de la longueur des phrases, du rapport nombre de mots/information, etc., etc.
Ces éléments sont quantifiables et leur optimisation, qu’il s’agisse de ceux qui déterminent la lisibilité optique/visuelle d’un texte ou son intelligibilité/compréhensibilité produit généralement les mêmes effets (personne ne comprend mieux les phrases avec une syntaxe inhabituelle, de mots longs, et non familiers, polysémiques dans un contexte donné, etc., etc. que leurs équivalents avec une syntaxe classique, des mots, brefs, familiers, monosémiques dans un contexte donné, etc., etc.)
Cependant, il y a des effets d’habitude et d’entrainement : un grand lecteur lira plus facilement des paragraphes longs qu’un lecteur lambda… mais il appréciera tout autant que ce dernier des paragraphes plus courts. Pour ma part, j’éprouve des difficultés à lire de livres disons imprimés avant les années 1970 car leurs caractères à empattement sont souvent trop étroits avec des déliés trop fins (dans le print, le support est limité et coûteux, et nombre de polices de texte “pré-web” ont des caractères plus étroits que des polices développées pour le web ; comparez une Times New Roman à une Georgia et une Arial à une Verdana).
Question : les lecteurs contemporains des livres publiés dans les premières décennies du 20e siècle lisaient-ils ces livres aussi facilement que je lis des textes en Verdana parce qu’il y étaient habitués, ou pas ?
Bref, tout ça pour dire qu’il y a une foule d’éléments objectifs et quantifiables de la lisibilité/intelligibilité, mais que la question est cependant complexe.
Et donc, les gens qui trouvent plus lisibles les gros blocs de code trouvent-il la lisibilité de ces blocs meilleure en raison de facteurs objectivables/mesurables ou par effet d’habitude ou d’entrainement ?