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
Discussion :
Bon, je crois que tu as gagné. C'est insurpassable, à mon avis.Envoyé par 4sStylZ
Mais comment on peut perdre intégralement les sources d'un projet ? Je veux dire, même en l'absence d'outil de versioning et en l'absence de backup, s'il y a plusieurs personnes qui bossent sur le projet, chacun a les sources sur son PC. Ils ont tous passé leur disque dur à la friteuse au même moment ou quoi ?
j'ai déjà vu ça - sur des docs. Le code, lui, était correctement versionné. Mais chaque développeur du projet(nous étions 4) avait fait sa petite doc. Puis l'avait envoyé au chef. Seul moi l'avait gardée sauvegardée. Le disque dur du chef à grillé, et je suis resté tout seul en maintenance. 25 jours de boulot pour refaire la doc de mes 3 camarades partis - et ayant tous conscienscieusement nettoyé leur PC(heureusement, c'était un petit projet, sinon j'en aurais eu pour deux ans).
Sur l'agl en question, aucun code n'est fait en local, on développait du client-serveur et tout code était saisie via un éditeur faisant parti de l'agl et le code envoyé sur un serveur de source contenant absolument tout le projet.Mais comment on peut perdre intégralement les sources d'un projet ? Je veux dire, même en l'absence d'outil de versioning et en l'absence de backup, s'il y a plusieurs personnes qui bossent sur le projet, chacun a les sources sur son PC. Ils ont tous passé leur disque dur à la friteuse au même moment ou quoi ?
Il y'avait des backup mais l'appli a été développé de 92 à maintenant, et les cd de backup de ce programmes trop vieux ont étés égarés.
---
Un vieil ami me racontait qu'il bossait dans une grande banque et à l'époque il était développeur sur certains projets et bossait en free lance.
Il se pointe à la cafet' et un mec lui sort :
- Tiens toi le programmateur! (j'en rajoute un peu mais bon on vous l'a déjà faite)...
- J'ai un petit truc à te demander, voila, je suis là depuis 2 ans et on m'a demandé de changer les bandes magnétiques et de les stocker tout les matins, et j'ai toujours eu un drôle de message.
Mon vieil amis vas voir l'IBM system 3X (qui en gros stocke des données bancaires vraiment, vraiment importantes...) et voit le message qui ressemblait approximativement à (pardonnez mon Anglais) :
"Error : recorder failed: no archived data".
Deux ans que le gus archivait des bandes vierges à la place des backup.
- Réutilisez vos variables ! Quand on n’a plus besoin de $adresse_ip, on peut bien y stocker un numéro de téléphone...
- Faites le moins de fonctions possible. Une seule fonction à laquelle on donne en paramètre ce qu’elle doit faire, c’est tellement plus fun à relire... Et ça donne une fonction qui sait tout faire ! Trop bien, non ?
Évidemment, si tout est au même endroit, quoi que tu cherches tu sais où le trouver !
Lorsqu'on voit ce genre de code, il y a des bouées pour rester zen :
Working Effectively with Legacy Codeet Clean Code: A Handbook of Agile Software Craftsmanship.
Ne pas réécrire un produit qui a plus de 5 ans et qui ne correspond plus du tout aux besoins, «*ça va plus vite de le modifier que de le réécrire et puis si il existe du code qui ne sert pas, bah c'est pas grave, on ne passe pas dedans. On ne supprime pas de lignes, on sait jamais ça peut servir.».
On récupère du code non documenté et non testé, vu sur le net sur un site pas connu. Si l'auteur dit que ca marche alors c'est que ca marche
Pas de commentaire dans le code, les commentaires c'est pour les nuls.
Pas de schéma de l'architecture du produit, pareil c'est pour les nuls.
Faut faire des docs, des specs, DAIs..... qu'il ne faudra surtout pas mettre à jour au fur et à mesure des évolutions. Comme ça on ne pourra pas nous dire qu'on n'a pas fait de doc.
En C++ on fait pas tous les constructeurs nécessaires ni les destructeurs (par copie, et les autres). Ça prend du temps et ça sert à rien. Pour récupérer la mémoire (qui coûte rien), t'as qu'a rebooter le poste...
Vendre un truc au client qui sert à rien, mais qui oblige à dupliquer beaucoup de code car c'était pas prévu et on n'a pas le temps de faire propre.
Utiliser au maximum Ctrl C, Ctrl V, c'est plus simple et çà va plus vite que de réfléchir.
Et "y'en" a d'autres.......
C'est exactement ce que j'ai pu constater dans beaucoup de projets dans des grands groupe et des banques.Ne pas réécrire un produit qui a plus de 5 ans et qui ne correspond plus du tout aux besoins, «*ça va plus vite de le modifier que de le réécrire et puis si il existe du code qui ne sert pas, bah c'est pas grave, on ne passe pas dedans. On ne supprime pas de lignes, on sait jamais ça peut servir.».
On récupère du code non documenté et non testé, vu sur le net sur un site pas connu. Si l'auteur dit que ca marche alors c'est que ca marche
Pas de commentaire dans le code, les commentaires c'est pour les nuls.
Pas de schéma de l'architecture du produit, pareil c'est pour les nuls.
Faut faire des docs, des specs, DAIs..... qu'il ne faudra surtout pas mettre à jour au fur et à mesure des évolutions. Comme ça on ne pourra pas nous dire qu'on n'a pas fait de doc.
En C++ on fait pas tous les constructeurs nécessaires ni les destructeurs (par copie, et les autres). Ça prend du temps et ça sert à rien. Pour récupérer la mémoire (qui coûte rien), t'as qu'a rebooter le poste...
Vendre un truc au client qui sert à rien, mais qui oblige à dupliquer beaucoup de code car c'était pas prévu et on n'a pas le temps de faire propre.
Utiliser au maximum Ctrl C, Ctrl V, c'est plus simple et çà va plus vite que de réfléchir.
Et "y'en" a d'autres.......
Mais là le code en C++ bourré de patchs datait de 1995 !!!!
Ingérable.
Mais là c'est de la faute aux développeur, jamais aux responsables projets et à la direction.
100% d'accord avec le reste.
Celui-ci, par contre, est un serpent de mer. Le "vieux code" a un tas d'inconvénients, mais aussi un avantage massif : il fonctionne. Et, de plus, il est généralement porteur d'innombrables corrections et ajustements qui l'ont rendu plus conforme.
Si on se contente de le jeter à la poubelle et de recommencer, alors on perd tout ce savoir-faire accumulé avec les années. Et on refera les mêmes erreurs que les anciens.
J'ai été amené à refaire au propre du code qui avait 36 ans d'âge(1972-2008). Je n'aurais jamais fait du bon travail si j'avais juste suivi les specs. J'ai ensuite fait un comparateur de résultats entre l'ancienne et la nouvelle chaine, qui m'a trouvé plus de 500 décalages. 2 étaient de vieux bugs de prods pas bien graves et jamais détectés. les 498 autres étaient des choses auxquelles personne n'avait pensé, mais que les anciens s'étaient mangé en pleine poire. Genre, pas de TIP pour les paiements à 1M€ ou plus, un type de courrier différent pour l'Alsace-Moselle, des conneries de ce genre, impossibles à prévoir tant que ça n'a pas planté. Ou qu'on a pas trouvé une différence entre le nouveau et l'ancien...
Quand on a pas les moyens de faire ce genre de vérifications(d'une manière ou d'une autre), garder l'ancien vieux et moche est généralement le bon choix.
Le quotidien.
C'est ce que je vois tous les jours sur un nombre incalculable de projets.
Des architectures détruites par des interventions et des modifs réalisées par du personnel débutant ou incompétent.
Une inconscience en ce qui concerne la robustesse ou la qualité du code, le règne du "je m'en foutisme".
Le non respect des règles de base du développement logiciel.
L'incompétence et la pratique du "parapluie" de la part des responsables projet et des clients.
Le "tout, tout de suite et pour rien" pratiqué dans les entreprises.
Le fait que le développement logiciel n'est plus un plaisir et une passion, mais seulement un gagne-pain.
Croire qu'un informaticien à la connaissance et la compétence universelle, dans les métiers clients et dans le vaste domaine de la science informatique.
Le manque de rigueur et la pratique du n'importe quoi.
Je me suis bien marré sur ce billet (et sur les commentaires), ça a réveillé des souvenirs d'anciens projets
moi mon problème c'est mon patron qui mélange tout le temps des données de test avec des données de prod et je passe des heures à trier
quand au vieux code git est la pour me le ressortir
je garde pas le vieux code dans mes fichiers plus de 2 itérations sinon j'ai trop de ligne à lire ^^
- ajouter des commentaires inutiles comme la date du jour où vous modifiez chaque ligne de code
- utiliser des variables globales au programme et écrire des fonctions sans paramètre ni retour pour gagner en performances
- ne pas utiliser au maximum le standard mais systématiquement chercher à le réimplementer sur chaque projet afin de toujours s'adapter au plus près du besoin
- mélanger vos "modifications personnelles", vos tests et le code spécifique à vos applications dans vos livraisons de code de composants réutilisables
- ne jamais documenter vos api externes. Préférez documenter d'obscures api internes a base de doxygens incomplets
... et j'en passe
commenter le code qui n'est plus utilisé ou l'ancienne morceau de fonction qui vient d'être ré écrit. Résultat au bout de plusieurs années, on arrive a des fichiers de plusieurs milliers de lignes avec la moitiée qui sont des commentaires.
La réponse qui m'a fait bien rire c'est que le développeur qui faisait ca le justifiait en indiquant que pour revenir en arrière en cas de problème/bug c'était plus simple.....
Petite pierre a l'edifice:
Avoir un projet en vbnet en prod mais pas avec les options explicites et autres:
=> solution qui ne compile pas mais ou les pages s'executent
=> sources sur le repo qui ne sont pas celles en prod
=> deploiment 'Only the brave'
Sinon special trick: avoir plein de services/executables partout qui pointent vers la prod mais qui s'executent depuis
=> la recette ( classique)
=> un serveur random (comment ca t'as pas lu le memo ? )
=> le pc de Francis (il ya toujours un Francis)
=> et en prime on a plus les sources de ces executable
Bien sur tous cela est du vecu
Répondre avec citation
Partager