Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ca c'est de l'interprétation. Un code qui a été réclamé pour répondre en franc et qui répond en franc, on ne peut pas le taxer de mauvais code parce qu'il n'a pas prévu de répondre en Euro. Ce n'est qu'un souci en amont. Ce n'est pas du ressort du développeur.Envoyé par disedorgue
Reprenez mon message, en respirant bien, et vous en comprendrez le sens. Un indice se cache dans sa première phrase.
En fait, on est d'accord depuis le début, ce code (qui n'est pas un mauvais code) ne fait pas partie du sujet de l'étude ?
Tant que les décideurs IT et les chefs de projet parachutés d'un école de commerce et sans expérience partiront du principe que:
- les développeurs sont interchangeables
- que 2 développeurs à 30K€ sont 2 fois plus productifs qu'un développeur à 60K€
on aura un système biaisé... et des projets avec des coûts de maintenance prohibitifs...
Les nouvelles méthodes managériales à grand coup de KPI n'aide pas non plus: car on crée une image instantanée fausse de la productivité (on produit beaucoup et vite avec beaucoup de vices cachés)...
Un bon code n'est pas juste un code qui fonctionne !
Je ne voudrais pas être désobligeant, mais à te lire, j'ai l'impression que tu n'as jamais codé. Il y a plein de codes qui "fonctionnent"... jusqu'à ce que tu modifies quelque chose, et là, c'est le bordel, et tu sais même pas déterminer pourquoi, tellement le code est un foutoir pas possible.
Donc, non, un bon code n'est pas seulement un code qui "fonctionne" (dans un état donné) ; ça, c'est pour les utilisateurs.
Un bon code doit également être un code bien organisé, bien structuré, bien commenté, optimisé, factorisé, minimal, lisible, intelligible, avec des conventions de nommage, conforme aux standards/pratiques actuell(e)s, etc., etc.
De mon point de vue, des codes absolument surdimensionnés, comme un jQuery pour réaliser des effets qui peuvent être obtenus avec quelques lignes de CSS, ou un Bootstrap pour réaliser un site one page, c'est aussi du mauvais code (les noms des classes CSS de Bootstrap sont très peu explicites).
Je ne nie pas que cela puisse exister, mais avec mon expérience (intégrateur web), j'ai beaucoup de mal à imaginer la chose. Faire ça volontairement serait tout simplement vraiment trop contraignant pour le codeur.Je mettrait tout de même un bémol sur les personnes qui écrivent volontairement leur code n'importe comment pour être les seuls à pouvoirs les maintenir et les faire évoluer correctement et facilement. Quoi qu'a ce niveau là ce serait plutôt le dev qui serait mauvais que son code finalement
De surcroît, s'il postule pour un nouvel emploi quel code pourrait montrer à un employeur un codeur tel que vous l'évoquez ? Et n'oubliez pas que dans le web, on peut consulter le code...
Enfin, dans le web, toujours, on travaille souvent en équipe. J'ai du mal à imaginer que quelqu'un qui fait du mauvais code (au moins) volontairement ne se fasse pas repérer tôt ou tard à tout le moins s'il n'est pas seul dans son domaine (front-end, back-end) à travailler dans la boite.
+1, et je vais troller pour en rajouter un peu : un code qui marche, c'est 50% du boulot, à peine.
Vous comparez des petits pois avec des citrouilles
J'ai lu et relu la première phrase de votre message ("C'est loin d'être l'apanage des devs.") et tout le reste de celui-ci en frôlant l'hyperventilation.
Je dois donc être totalement crétin.
Je ne nie absolument pas que les comportements que vous citez existent, et c'est évidemment déplorable. Simplement, vous comparez des petits pois avec des citrouilles. De par mon expérience (intégration web), le mauvais code est un problème grave et n'a rien à voir avec des comportements vexatoires pour cause de faute d’orthographe inaperçue ou d'accent d'un intervenant.
Ne vous critiquez pas de cette manière, vous n'avez simplement pas compris le parallèle (ou alors je me suis mal exprimé).
Le parallèle ne se situe pas au niveau du code, mais il dénonce l'argument qui explique que les devs s'acharnent sur des petits détails.
D'une c'est faux (tous les devs ne font pas ça), de deux c'est une pratique que l'on peut retrouver à tous les étages d'un projet.
Le code, l'accent, la faute, le terrain... tout est excuse à être inutilement pointilleux, et donc à pénaliser un projet.
Ce n'est pas un "détail"
Encore une fois, je ne conteste pas que les comportements que vous évoquez existent, et c'est effectivement déplorable.
Encore une fois, je ne vois pas en quoi le fait critiquer un mauvais code, et, dans mon cas et dans la foulée, de devoir refaire des site web (il s'agissait de sites vitrines) from scratch, tellement le code initial est inutilisable (n'importe comment, le job, c'était de les refaire) relève du "petit détail".
Nombre de codeurs doivent rattraper des trucs vraiment infâmes, pas des "petits détails"... et dans l'incompréhension générale, avec comme réponses des arguments du genre "tant que ça marche".
Encore une fois, critiquer (de manière pertinente) un (réellement) mauvais code (et l'optimiser ou le refaire si on en a la possibilité) ne pénalise pas un projet, ça le sert.
En fait, en assimilant les critiques de devs sur le mauvais code à un acharnement mesquin et vexatoire, vous ne faites malheureusement que retomber dans les critiques habituelles qui leur sont adressées (peut-être à votre insu, voir le quatrième lien ci-dessous), le genre "tant que ça marche, c'est bon, je vois pas avec quoi tu viens".
Et n'oubliez pas, si le code est mauvais, en cas de refonte de son site, c'est le client qui risque de payer le surcoût dû à une refonte from scratch au lieu d'une simple évolution.
Je vous mets quelques liens qui vous aideront peut-être à mieux comprendre mes préoccupations :
Les principes de simplicité appliqués au design et au développement Web
Arrête de faire ton Homer !
L’expérience utilisateur d’un grille-pain
Soin et alimentation des ingénieurs informatique (ou pourquoi les ingénieurs sont grincheux)
Web 2018 : plus lourd, plus lent
Bonnes lectures.
C'est Stripe qui le dit.Les développeurs consacrent trop de temps à corriger le mauvais code
Ecoute-moi monsieur Stripe !
1- Qui d'autre qu'un développeur peut corriger du code qui n'est pas (ou plus) correct ?
2- Samedi dernier j'ai vu ta formidable plate-forme de paiement planter, et à cause de cela, le site web sur lequel j'essayais d'acheter quelque chose a perdu un client. Donc tu devrais peut-être laisser tes développeurs corriger le mauvais code.
- Une API REST c'est juste du CRUD
- La base de données en NodeJS c'est Mongo (et puis SQL on connait pas donc on zappe)
- Côté front, il faut que ça soit simple, donc on va faire un seul formulaire qui fait tout dans tous les contextesC'était une appli de gestion multi acteurs qui devait faire avancer un dossier commun, du genre à la fin chacun devait signer numériquement les documents des autres, avec gestion des modifications, historique (qui ? quoi ? quand ?), notifications etc. Donc hautement relationnel.
Donc beaucoup de métier, et si les services back ne s'en occupent pas, image la taille et les responsabilités du Front..
Par ailleurs c'était un service, pas du spécifique à un client, service potentiellement intégré aux outils d'autres éditeurs. S'ils n'ont juste accès à un point vers une base de donnée, ils vont devoir se retaper tout le métier. Quel intérêt du coup ?
Enfin, un mec qui connait un peu le front pouvait mettre ce qu'il voulait en base de données, c'est comme s'il avait login / mdp de la base finalement.
Moi aussi ça m'énerve ce sacro saint objectif "tant que ça marche.."
Les gens quand ils achètent une voiture ils en veulent un peu plus pour leur argent qu'un simple "tant que ça roule..", surtout avant de mettre leur gosses dedans.
Ah oui dans ce cas, effectivement ça part en couille ...
[ mode sarcastic ON] Un service sans auth pour de la gestion multi-agent mais c'est génial en fait tu peux filer tes erreurs à quelqu'un d'autre. tu devrais être heureux le débogage de qui as fait quoi va être génial, tu vas avoir un taf assuré à viepour peu que tu est un contact parmi les users tu dois pouvoir faire passer des notes de frai signé par vous en faisant croire que c'est signé par le service compta ^^ [ mode sarcastic OFF]
Oui c'est ça, si je te file l'URL du service, tu y vas, tu es dedans et en avant les petites histoires, tu te fais passer pour qui tu veux et tu fais ce que tu veux.
Heureusement que c'est à destination du monde bancaire, ça serait l'épicerie du coin je te dis pas les conséquences..
Mais bon, ils n'avaient pas le temps pour ce genre de broutille back que le client ne voit pas, mieux vaut péter toute l'énergie sur des jolis boutons.
Autre hypothèse, le budget et le temps alloué aux projets est insuffisant pour atteindre un niveau de qualité qui permette de ne pas passer ensuite une quantité de temps démesurée sur la maintenance du système branlant qui a fatalement fini par en ressortir à force de trancher les moyens disponibles au sabre.
vécu. Un exemple? L'équipe précédente s'était vue demander de faire un batch de traitement des campagnes marketing. Ils ont fait une étude, ils ont proposé un prix, on leur a dit "trop cher, divisez par trois le prix". Et ils ont réussi! Mais c'était un truc branlant et inmaintenable. Je ne peux pas leur en vouloir. Ca pétait grave tous les mois(pour une chaine mensuelle, hein...), mais ça faisait le boulot, une fois qu'on avait passer trois jour à tout remettre d'aplomb. C'était impossible à faire évoluer, aussi, et à la première demande d'évolution un peu burnée, on a du tout refaire. En mieux.
+1n !
Combien de délais de réalisation de projets sont-ils fixés trop court/-cher par des commerciaux ? Est-ce la faute des devs s'ils passent "trop de temps en maintenance" à cause de délais fixés trop court ?
Et comme en plus, souvent, le budget de la maintenance n'est pas le même que le budget des projets, les décideurs sont en fait motivés à prendre ce genre de raccourcis, injustifiables si on regarde la situation globale.
Mon dernier "décideur" (le CTO) a passé 3/4 de sa vie professionnelle à être décideur dans des événements de musique électronique (le genre de truc sous coke jusqu'à 6h du mat'). Puis il est devenu décideur dans l'IT...
Un décideur c'est un décideur après tout, 20 piges dans la décision c'est pas rien, toujours rangé derrière "si ça marche pas c'est qu'ils s'en foutent".
Plus tard je ferai décideur, ça a l'air pas mal et bien payé cette histoire. Ce matin j'ai décidé de manger des Chocapics, je tiens quelque chose dans le milieu.
Edit : Et j'ai dit "fou le camp à mon chien", j'ai donc également une graine de management ;-)
Il en reste que la qualité de la maintenance, d'accompagnement au fil de la vie du produit, est un critère déterminant de choix d'un prestataire informatique.
Chez nous la maladie de pas mal de devs c'est de reinventer la roue ... carrée.
En 2018, pour des applis de gestion, je ne comprends pas qu'on reinvente des frameworks maison, alors que bien souvent notre metier (sur la partie technique) devrait se limiter a faire de l'assemblage de composants existants (hors code purement logique metier bien sur).
On ne cherche pas a voir ce qui existe deja et qui pourrait faire le boulot, on reecrit (avec les bugs bien sur).
Ca c'est vraiment du temps perdu. De plus certains ont l'art de complexifier l'archi des logiciels (c'est surement pour donner du credit a ce qu'ils font).
Personnellement la maintenance est simplifiée et peu couteuse des lors que la conception est simple et modulaire.
Ca permet de resoudre efficacement n'importe quel probleme. Je dis toujours, si c'est complexe a coder c'est que la conception est mal foutue. Ca s'est toujours verifié en pratique sur tous les projets sur lesquels j'ai travaillé.
Je prefere largement une bonne conception simple et des devs moyens que des conceptions complexes (a cout de multiplication de technos et autres mille feuilles logiciel) et des 'ninja du code' (qui satisfont leur ego mais rendent le code inmaintenable par quiconque).
Surtout qu'un prestataire peut se faire plaisir (on a vecu le cas au moins 2 fois et ca nous a couté enormement en maintenance), il s'en fout il n'assurera pas la maintenance sur le moyen/long terme mais ceux qui doivent recuperer/gerer le(s) appli(s) et c'est souvent là le drame (de mon experience). Repasser derriere des devs qu'on a laissé s'amuser avec les technos (pas toujours justifié) c'est catastrophique pour la maintenance par la suite.
Répondre avec citation
Partager