Actualités

p. 06 Nouveau langage Perl 6 : une expressivité sans précédent

Humeur

p. 14 Code et maintenabilité

Repères

p. 16 Peut-on vraiment calculer avec un ordinateur ?
p. 22 Expliquer un code QR
p. 28 Déchiffrer un code QR

Sysadmin

p. 32 Mettre en place un bureau virtuel sur son serveur dédié
p. 38 Tomcat en version « Stateless »
p. 46 Git init /etc

Les « how-to » du développeur

p. 52 Rédiger son article avec Asciidoc[tor]

Développement

p. 56 Écrire son thème Asciidoctor
p. 64 Il ne lui manque que la parole...
p. 72 Le Graal à portée de main: écrire un interpréteur

Développement web & mobile

p. 78 Android Context : Quel Context utiliser dans votre application Android ?

La complexité est un problème auquel tout développeur est confronté un jour ou l’autre et autant que ce soit le moins souvent possible ! La complexité ? Non, je ne parle pas de complexité algorithmique qui est nécessaire et permet d’optimiser le code. Il est question ici de la complexité induite par certains développeurs dans leurs programmes. N’avez-vous jamais rencontré un code censé réaliser une tâche extrêmement simple et clairement définie sans pour autant pouvoir le lire rapidement ? Un effet pernicieux de la fatigue ? Non, simplement un individu qui souhaite étaler son savoir, montrer qu’il « sait » de quoi il parle. Ainsi, pour répondre au problème « écris une fonction permettant d’additionner deux entiers », là où un développeur consciencieux se limiterait à l’écriture effective de ladite fonction, ces individus vont définir au minimum deux classes et une interface (et s’ils ont le moyen d’utiliser l’héritage, ça ne sera que mieux).

Quid de la philosophie UNIX : « ne faire qu’une seule chose, mais la faire bien » ? À quoi bon développer un système capable d’effectuer des opérations sur les nombres complexes quand on demande une simple addition d’entiers ? Cet exemple est bien entendu abrégé mais, aussi contradictoire que cela puisse paraître, la plus grande difficulté est de simplifier les choses. Pour pouvoir travailler en équipe et maintenir du code, il faut être capable d’écrire des instructions claires au sein d’une architecture qui aura peut-être demandé des heures de réflexions, mais paraîtra évidente. Le développeur qui « étale sa science » est un nuisible pour l’équipe, une source de perte de temps et de tensions (essayez de discuter avec quelqu’un qui a forcément raison).

Si nous changeons de domaine, prenons le dessin, n’importe quel étudiant des beaux arts sera capable de dessiner un « bête » taureau. En retrouver les lignes essentielles sera un travail autrement plus complexe et la vue du résultat final passera pour une évidence. On pourra entendre « un enfant de maternelle peut le faire » ou « moi en cinq minutes je fais la même chose »... Certes, une fois que le résultat est là, que tout le travail de simplification a été effectué, la reproduction sera plus aisée. Si vous cherchiez une idée de destination pour vos prochaines vacances, vous pourrez théoriquement voir les onze états successifs de la lithographie « Le Taureau » de Pablo Picasso au MoMA (Metropolitan Museum of Art). Mais comme les œuvres voyagent, il n’y sera peut-être pas... avec un peu de chance, vous pourrez la voir en France (elle était à Beaubourg il y a quelques années). Sinon on peut aussi en trouver des photos sur internet : http://www.moma.org/collection/works/62951 pour l’état III ou encore http://www.moma.org/collection/works/63062 pour l’état XI. Vous comprendrez de quoi je veux parler.

L’idée est la même lorsque l’on effectue une présentation devant un auditoire : créer des slides bourrés de texte, de code et d’équations est à la portée du premier venu. Simplifier le propos, alléger les supports visuels tout en expliquant des choses complexes, là est la réelle difficulté et la réelle preuve de maîtrise. Pour y parvenir, il n’y a qu’une solution : rester humble et continuer à apprendre, par exemple en lisant GNU/Linux Magazine...

Bonne lecture !

Tristan Colombo