le Code est-il vraiment sans valeur ? Décryptage d’un expert

VILLE – 8 Mai 2024 –

Cet article examine la véritable valeur du code dans le développement de logiciels.Il s’interroge sur l’importance du code par rapport à d’autres aspects cruciaux tels que le temps, la compétence et la conception. Il explore les raisons pour lesquelles le code, bien que nécessaire, pourrait être moins vital qu’on ne le pense. Pour en savoir plus sur cette perspective provocatrice, continuez votre lecture.

L’argent, c’est du temps, le temps, c’est de la valeur.

Admettre que votre logiciel est sans valeur était une tactique d’accroche.Il n’est pas aussi précieux ou indispensable que vous le pensez. Deux éléments sont nécessaires pour résoudre un problème avec un logiciel : la compétence et le temps.

La compétence est essentielle. On peut créer du code avec des praticiens non qualifiés. Le code peut même fonctionner, mais ce n’est pas la même chose que résoudre le problème. Un mauvais code est un problème en soi.Même si vous résolvez votre problème initial, vous en avez un nouveau, potentiellement plus vital, à gérer. Le talent ne coûte pas cher.

Le codage peut être rapide, mais résoudre des problèmes est délicat. Cela prend du temps, et le temps, c’est de l’argent. Une équipe de développement de logiciels coûte cher à faire fonctionner. Tout logiciel décent entraînera des coûts importants. Si vous investissez dans votre solution, attendez-vous à ce qu’elle ait de la valeur une fois terminée.

Pourquoi suggérer que le code est sans valeur ? S’il résout le problème, il apporte de la valeur.”Sans valeur” semble un peu dur. C’est vrai que j’exagère, mais pas beaucoup. Pour comprendre, regardons à nouveau cette solution et le temps qui y a été consacré. Il est facile de se concentrer sur le logiciel et d’ignorer ce qui l’entoure.comment faire un gâteau ?

Premièrement, il y a l’équipe. Il faut trouver les bonnes personnes, compétentes, et les réunir. Ensuite, elles doivent établir des rôles et des responsabilités clairs et apprendre à travailler ensemble en équipe. Enfin,cette équipe doit établir des relations avec les parties prenantes et les utilisateurs,et se familiariser avec l’espace du problème.

cela prend du temps.

Deuxièmement, il y a la logique métier. Même la plus simple des solutions doit effectuer un certain traitement métier. Quelqu’un doit déterminer quelle doit être cette logique et la codifier.

Cela prend du temps.

Troisièmement, il y a la conception. Si le code est destiné à l’utilisateur, il offre une expérience à l’utilisateur. Cette expérience est (espérons-le) développée au fil du temps grâce à une conception soignée, des commentaires et des itérations.

Cela prend du temps.

Enfin, il y a le code. Cela prend aussi du temps, mais ce temps est faible par rapport à tous les autres.Parfois, on a l’impression que tous les efforts sont consacrés au code et que les autres parties sont accessoires. En réalité, très peu de temps productif se retrouve sous forme de code dans la solution en direct.

Une partie du code sera remplacée par des alternatives dans le cadre de l’approche itérative de feedback. Une partie du code restera, mais ne sera plus utilisée en raison de modifications de la conception. Une partie du code aura été écrite en prévision d’une situation qui ne se présente jamais.

La réponse du développeur à tout cela est le « refactoring ». Pour ceux qui ne codent pas, le refactoring est le processus de révision du code existant et d’apport d’une série d’améliorations tout en conservant la fonctionnalité de base.Cela prend du temps.

La connaissance, c’est le pouvoir.

Lorsque vous additionnez tout le temps, vous obtenez le coût de votre solution logicielle, et vous pourriez soutenir que cela représente la valeur du code. Vous pourriez même soutenir que la valeur du code dépasse le coût.

C’est là que je ne suis pas d’accord. Mon opinion est qu’en faisant cela,vous confondez la base de code et la solution. Toute la valeur est stockée dans l’équipe, la logique et la conception, et très peu dans le code lui-même. Au départ, ce point de vue n’était qu’une hypothèse sans aucune forme de preuve, mais au fil du temps, j’ai eu l’occasion de mener des expériences pour tester cette hypothèse.

Une expérience particulière concernait un portail web auquel j’ai participé au développement dans le cadre d’une équipe entièrement à distance juste avant le tournant du millénaire. Les smartphones n’existaient pas et l’internet était encore un concept relativement nouveau pour beaucoup de gens. Le portail était destiné à un fournisseur de services internet en pleine croissance.

Il a fallu six mois à une équipe de seulement sept personnes pour développer le travail, et le résultat a été une solution multiplateforme capable de fournir du contenu, du courrier électronique, un calendrier et de la messagerie.Il était en avance sur son temps et prenait également en charge l’interaction vocale via un téléphone mobile et la diffusion de contenu via WAP. Qu’est-ce que le WAP ? Cherchez-le sur Google : l’époque précédant les smartphones était loin d’être sophistiquée en matière d’accès mobile à l’internet.

Le résultat était suffisamment bon pour être racheté par une grande organisation en tant que solution de portail. Cette société avait déjà passé plus de six mois avec une équipe beaucoup plus importante à essayer de créer la même chose sans succès. Nous étions fiers de ce que nous avions accompli en si peu de temps et avec une équipe si réduite.

Mon expérience portait donc sur quelque chose qui était déjà considéré comme très efficace en termes de développement de code.

Nous pouvons le reconstruire !

J’ai passé quelques semaines chez moi à recréer la solution à partir de zéro. Le code appartenait désormais à un tiers, je voulais donc une version entièrement nouvelle que je puisse appeler la mienne. Je n’ai rien utilisé de l’original, à part ma propre connaissance du problème et mon expérience pour le résoudre. Le référentiel de code n’était plus accessible, je ne pouvais donc rien en copier, même si je l’avais voulu. Cela aurait également été contraire à l’éthique, car il ne m’appartenait pas. Chaque ligne de code a donc été réellement construite à partir de zéro.En deux semaines, j’avais une solution entièrement fonctionnelle qui faisait tout ce que l’original faisait (et un peu plus). J’avais réussi cela en un rien de temps et j’avais généré une fraction du code par rapport à la solution originale.

Comment ai-je réussi cela ? Étais-je une sorte de génie du codage ? Évidemment que non. J’étais un codeur très compétent, au sommet de mon art, mais je n’étais qu’un seul codeur. Quelle que soit votre qualité, il y a une limite à la vitesse à laquelle vous pouvez taper.

Non. J’ai réussi cela parce que le code contenait très peu de la valeur réelle. Tout cela était stocké dans ma tête. La conception était dans ma tête, et avec le recul, je pouvais voir tous ses défauts. J’ai donc pu créer une conception beaucoup plus efficace et performante basée sur cet apprentissage. toutes les erreurs avaient été commises, j’ai donc pu obtenir cette version du code du premier coup. La plupart de mes tests se sont déroulés avec succès et le temps de débogage était presque inexistant.

Je savais maintenant ce qui n’était pas nécessaire.Toutes ces choses que nous avions intégrées pour répondre aux besoins anticipés pouvaient maintenant être réduites à celles qui s’avéraient vraiment utiles. Je comprenais chaque élément de technologie, chaque protocole et chaque bibliothèque, il n’y avait donc pas de courbe d’apprentissage.

Presque sans valeur.

Je peux en conclure que sur les six mois passés par sept personnes à créer cette solution, presque rien n’était lié au code. Il pouvait être complètement mis au rebut et reconstruit par une seule personne en moins de deux semaines. De plus, il pouvait être radicalement amélioré en même temps.

C’est pourquoi j’affirme que votre code est sans valeur par rapport à l’effort global investi dans la création de votre solution. J’irais même plus loin. Je suggérerais que, contrairement à ce que l’intuition pourrait vous dire, le refactoring pourrait être mieux réalisé en jetant le code et en recommençant.

C’est une pensée effrayante. Vous pourriez même la considérer comme ridiculement farfelue. je ne m’attends pas à ce que vous soyez d’accord avec moi sur la base d’un article de blog.Je vous recommande toutefois d’y réfléchir sérieusement et de mener peut-être votre propre expérience similaire. Si vous le faites, faites-moi savoir comment vous vous en sortez. Je serais vraiment intéressé de le savoir.

Suis-je spécial ? Suis-je le développeur mythique dix fois plus performant ? Personnellement, j’en doute fort. Après tout, j’étais l’une des personnes qui ont mis six mois à le construire la première fois.

N’oubliez pas cela la prochaine fois que vous devrez corriger le code de quelqu’un d’autre. Il est facile de se sentir supérieur et compétent. Il est tentant de rire des erreurs évidentes commises par ceux qui nous ont précédés, mais vous avez l’avantage du recul.Considérez plutôt que vous vous tenez peut-être sur les épaules de ceux qui ont tracé le premier chemin que vous devez suivre.