Discussion :

[Cincinnatus]

Il y a quelques temps, j'ai fait un rappel des fonctionnalités réalisées et livrées d'une part, restant à faire d'autre part.
Réponse : j'aurais fait ça pour gagner du temps...
Non, juste parce que la maîtrise d'ouvrage ne fait pas son boulot.
D'où des changements de priorité très (trop) fréquents. Ceci peut (si si) avoir un impact sur la qualité du code.

[ManusDei]

En fait, au début du projet, tu as raison. Commencer aujourd'hui un nouveau système en Scala, Ruby, ou je ne sais quel langage relativement récent(y'a sans doute encore plus récent, je ne suis plus très au jus), c'est parfaitement légitime.

Par récent, perso j'imaginais plutôt GO, le langage que Google a pondu l'an dernier (et qui je crois est déjà plus ou moins abandonné).

[Traroth2]

Par récent, perso j'imaginais plutôt GO, le langage que Google a pondu l'an dernier (et qui je crois est déjà plus ou moins abandonné).

Non, pas du tout. La version 1.2 de Go est sortie hier.

Cela dit, tu as raison : Scala est assez récent, mais Ruby est plus vieux que Java...

[kikotte]

Pour ma part, là où je travaille :
- on met tous les JAR de l'appli Java EE dans le dossier /lib/ de Tomcat ("Tom 4" comme dirait mon chef), comme ça, on évite se prendre la tête avec Maven ou Ant.
- on créé du coup les WAR à déployer dans Eclipse, comme ça, on a pas besoin de configurer Nexus et Jenkins.
- le tests (unitaires, non régression, etc.), c'est une perte de temps.
- le serveur de test sert de serveur de développement, et on teste en prod, c'est plus simple.
- encourager les utilisateurs à utiliser Internet Explorer en mode dégradé (W3C, c'est bien la coupe du monde de jeux vidéo, non?).


Powered by Norme ISO-1664 from La Rache !!

[mangobango]

- mélanger les dépendances aux licences incompatibles
- autoriser plusieurs dépendances recouvrant la même fonctionnalité
- intégré dans un projet multi-plateforme des dépendances non-portables...
- importer tous les symboles localement sans discernement, comme ça on ne sait pas d'où vient qui.
- monkeypatcher à outrance

[terence]

Serieusement traduire STAGING par mise en scene????

[yoday38]

Par rapport à un projet que j'ai récupéré récemment :
- avoir oublié de committer son projet avant de quitter le boîte
- avoir comme seuls commentaires des choses comme ça : "Lignes merdiques mais à mettre absolument"
- mettre des noms de méthodes n'ayant rien à voir avec ce qu'elles font.

[Jitou]

Pas mal toutes les recommandations déjà invoquées mais j'en rajouterai une, payez vos développeurs comme des employés administratifs et vous aurez du travail à la hauteur de vos espérances ...

[SylvainPV]

Utilisez un tas de différents langages de programmation et restez à la pointe : essayez les derniers langages qui font le buzz. Tout programmeur qui se respecte peu apprendre un nouveau langage en peu de temps, alors si le prochain développeur qui viendra travailler sur votre code est novice ce n'est pas votre problème.

Je suis plutôt d'accord avec ça, si ces langages sont vraiment mieux adaptés. On ne va pas utiliser éternellement les mêmes technos sous prétexte qu'on doit pouvoir coller n'importe qui au projet plus tard, sinon plus aucune innovation n'est possible. Et parfois on rend même service au prochain développeur. Personnellement, j'ai déjà découvert de nouvelles bibliothèques en reprenant des projets existants, et je les réutilise maintenant dans d'autres projets.

[23JFK]

• Ne jamais faire simple quand il y a moyen de pondre un code tarabiscoté.

[kyrilkarlier]

Bonjour à tous,

cela fait maintenant 5 ans que je fais dans de la maintenance applicative... et chez nous le service informatique à 0 € de budget .... puis que ce sont les services qui décident de payer ou non pour un logiciel !!

Du coup, lorsqu'une évolution est demandée, nous disons attention cela a un fort impact... le service répond "c'est nous qui payons, nous le voulons..."

Nous le faisons faire par l'éditeur qui rechigne aussi à le faire car c'est une belle connerie !

Au final, une gescom qui devait rester 10 voir 15 ans ne fera que 5 ans et au final également le SI a un budget un droit de veto sur tous les développements... après plus de 2M d'€ de perdu en 5 ans !

[lamaison]

Le pire à mon avis :
Bien entourer son code avec une gestion des erreurs .. non gérée.
Le programme ne plantera plus jamais ( le développeur est vraiment très fort et va bénéficier d'une belle promo dans un autre service ).

Histoire vraie : quand je suis arrivé derrière, le programme était un champs de ruine entouré d'un joli papier cadeau, un vrai cauchemar.

[band5711]

l'AGL facilite le travail collaboratif et la gestion des sources des projets est optimale

[hotcryx]

- utiliser des noms de variables à rallonge et ambigus:
ex: cmdeArticleDecryptedEncrypedAddressDescription

- chaque méthode renvoit true/false (ou 1/0), ce qui veut dire que chaque méthode appelante comprend un nombre incalculable d'alternative comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if (!functionA) return false;

if (!functionB) return false;

C'est vachement cool pour les tests et comprendre la logique

- utiliser une usine à gaz pour générer des librairies employées dans tous les autres projets (un générateur de code).

Ce qui veut que lorsqu'une dépendance change, il faut tout recompiler et qu'on retombe dans le problème du support et de "comment fonctionne ce brol!".

Rem: j'ai actuellement tous ces cas de figure dans une même application, le "développeur" étant parti.

- A cela rajouter des batches (process) qui doivent tourner inter-systèmes comme SAP, FTP... avec des emails d'erreurs non détaillés et vous vous noyez dans le process.

PS: j'ai mis 2h pour trouver ou était initialisée une variable dans le code:
j'ai dû parser tous le code en descendant et en remontant les appels de fonctions car c'était la variable d'à coté!

Solution: ce dégager au plus vite de ces projets, les laisser mourir ou tout recommencer sur de bonnes bases.
C'était littéralement de l'obfuscation de code, sans parler des bugs, mauvaise gestion des exceptions.

Anecdote: quand le développeur était encore là, il nous disait avec un grand sourire:
"Quel beau code! Ca se lit comme un roman."

[GLDavid]

Bonjour

Allez, j'y vais de ma contribution que j'ai vécu et que je subis encore:
Devoir supporter un framework et un gestionnaire de contenu entièrement développé in house en PHP alors que la même chose (en moins buggé) existe dans le commerce ou en libre !

Et oui, chers amis ! N'est-il pas plus simple que de réinventer la roue parce que:

Une solution propriétaire coûte de l'argent et les solutions open-source ne sont pas pérennes

Voilà ce que j'ai entendu et que je dois encore vivre dans ma boîte.
Au final, je me retrouve avec une application web PHP que je dois supporter seul (sinon, c'est pas rigolo) et avec la certitude d'avoir un code "papillon": une modification à un endroit entraîne une conséquence non-prévu ailleurs.

Ah oui, j'oubliais, notre framework n'est pas documenté et on se retrouve avec des doublons et un mélange avec Javascript, Perl et Java dans du PHP des plus exquis.

Please, quelqu'un qui aurait besoin d'un bio/chemoinformaticien ???

@++

[el_slapper]

Il peut y avoir plein de raisons valides de réinventer la roue. Mais, ça nécéssite généralement pas mal de ressources et de spécialistes pour quelque chose d'aussi central que le framework.

Si on a à faire à des gens ne serait-ce que moyens, sur un point qui n'est pas stratégique(le site web est stratégique, pas le framework sur lequel il est basé), c'est un aller simple vers l'enfer garanti, en effet.

[I_Pnose]

Allez, parce que je le vis en direct-live :

• Reprendre le code d'un collègue et se retrouver avec très exactement 2166 lignes de code dans le code-behind de l'unique vue d'une application WPF (et de préférence avec un try/catch qui englobe l'instanciation de la vue dans le main). Bref, j'ai très envie de pleurer, pour de vrai --".

[4sStylZ]

Alors... De mon coté :
- Des BDD différentes selon les environnements.
- Des SGBDR différents selon les environnements. (Sybase-Oracle... *sigh*)
- Un seul et même environnement pour le développement, la recette (mais heureusement pas la prod).
- Une appli vendue comme étant basée sur un framework mais qui ne l'utilise pas du tout.
- Une appli optimisée pour IE avec la google chrome-frame...
- Plusieurs bibliothèques logiciels inconnue sur la terre, et dont la doc est en Klingon ou un truc du genre.
- Du code condensé en développement, si si.
- Pas de norme, pas de commentaires, et je ne saurais parler d'architecture pour un bidonville pareil.

Et pour finir, la perle :

- Une série de programme censés être développés de la sorte :
1) Programmation par un AGL qui compile un code source (lisible) qui lui même est 2) recompilé dans un langage propriétaire dont les sources sont 3) détruits sur la production.

Normalement si on veut maintenir un tel programme, il est logique de tout maintenir à partir de l'AGL...

- Ces sources, censés être maintenu l'AGL ont étés modifiés dans le langage de milieu niveau puis recompilés. Tout les source, que ce soient de l'AGL ou ceux du niveau moyen ont étés détruits. La seule solution pour maintenir le code c'est de tester le programme et de pratiquer une rétro ingénérie (Sur deux langage différents), mais là ou tout se corse, c'est que la dernière version du programme à maintenir est sur un OS propriétaire et sur la production uniquement. Il n'y a absolument accès à aucun binaires...

On est donc obligé de faire des tests en production pour cette rétro ingénérie...

[el_slapper]

ça me rappelle mon père qui s'était coltiné(au début des années) un mélange d'APL et d'assembleur, l'APL étant commenté en slovaque, et l'assembleur en Allemand.

Le tout à reprendre en COBOL sur un site Français. Bon, être quasi-bilingue Allemand l'a aidé, mais le slovaque.....

[Nicam]

C'est marrant, je ne suis pas spécialement fan des commentaires, et je vous dis pourquoi :

1 - les commentaires, par expérience, sont souvent évident. Pour moi, le commentaire doit donner des explications fonctionnels, et non pas justifier techniquement le code. UN code bien ecrit doit permettre d'etre compris rien qu'en le lisant. Par contre, pourquoi on a placer ce bout de code, au niveau fonctionnel, ca a du sens.

2 - En maintenance, bien souvent au fil du temps, on modifie le code, mais pas les commentaires. Au final, le nouveau dev qui débarque est induit en erreur. L'effet obtenue est bien souvent pire que l'absence de commentaire en lui même.

Enfin, pour compléter la liste des choses à faire, j'ajouterai :
Se contenter du mondialement connu : ca marche sur ma machine (je suis sure que vous l'avez déjà tous vu celui là


EDIT : absence de commentaire en lui même, et non pas absence de code en lui même.