Une vue mal alignée : donner la priorité aux pairs par rapport aux utilisateurs

Combien de fois avez-vous regardé le code de quelqu’un et déclaré :

Je ne l’utilise pas car il n’a pas l’air bien écrit.

Et dans ce cas, "avoir l’air bien écrit" pourrait soit remplacer :

• "ressemble à la façon dont je l’écrirais,"
• "m’a l’air d’avoir un sens."

Bien sûr – il y a des moments où l’utilisation de code open source est risquée. Nous le savons grâce aux différents logiciels et services qui présentent des vulnérabilités. Mais, au moins pour ce poste, traitez-les comme l’exception – pas la règle.

Cela signifie qu’il nous reste à regarder quelque chose que nous pouvons utiliser mais que nous choisissons de ne pas utiliser car il ne semble pas être écrit d’une manière que nous pensons qu’il devrait être écrit.

Donner la priorité aux pairs plutôt qu’aux utilisateurs

Le développement est délicat car il y a plusieurs compromis que nous – ou un autre développeur – devons faire chaque fois qu’ils construisent quelque chose.

Regarder à l’envers

Nous devons considérer :

• contraintes de temps et de budget,
• quel paradigme nous aidera à livrer un solide dans lesdites contraintes,
• la solution finale résout-elle vraiment le problème central,
• y aura-t-il des coûts de maintenance associés à la façon dont nous avons assemblé quelque chose ?

Et la liste pourrait continuer.

Considérer les différents aspects du développement et débattre des philosophies sur la façon dont quelque chose devrait être construit n’est pas du tout rare dans notre industrie

Mais cela prend aussi beaucoup de temps, et cela peut s’avérer être un exercice qui donne un résultat net nul car rien n’en ressort. (Oui, cela peut souvent être une expérience d’apprentissage, mais pas toujours.)

Photo de José Alejandro Cuffia sur Unsplash

Regarder à l’extérieur

Pratiquement parlant cependant :

• Le paradigme utilisé pour créer la solution a-t-il un impact sur votre utilisation du logiciel ?
• Le logiciel en question résout-il le problème ?
• Si vous n’étiez pas en mesure de voir comment le projet a été assemblé, quelle conclusion tireriez-vous du logiciel ?

Et le dernier point est peut-être le plus critique en ce qui concerne les logiciels open source.

J’ai travaillé dans l’industrie assez longtemps pour savoir que souvent les gens veulent une solution fonctionnelle qui résout leur problème et ils supposent qu’elle est solidement construite.

Les développeurs, quant à eux, examineront davantage le code que la solution qu’il fournit et le problème qu’il résout.

Si vous êtes un développeur, il y a absolument un moment et un lieu pour les deux. Mais si vous laissez ce dernier vous empêcher d’expédier le premier, vous risquez de ne jamais sortir quelque chose pour que d’autres puissent l’utiliser parce que vous êtes trop préoccupé par ce que vos pairs peuvent penser.

Et lorsque vous résolvez un problème pour d’autres personnes, elles devraient être celles qui comptent plus que vos pairs.