Discussion :

[rad_hass]

Bonjour à tous,

Je débarque dans un grand projet d'un grand compte (vois très grand), qui est plutôt intérescent, avec une équipe ma foi fort sympathique. Jusqu'ici tt vas bien, mais c dans la suite que ça se gate :

Je dois développer des nouveaux modules, sauf que ceux qui a été fait avant (dans une TG SSII au forfait au passage -> Travail pas satisfaisant pour le client donc dev en interne) me pose légérement pb. Je vous explique (un petit aperçu) :

Dans le code-behind du ASP.NET, je tombe sur des appels à des procédure stocké(Résultat dans DataSet ). Et il n y pas d'objet métier ...

Donc pas d'archi n-tier

Ce qui donne des pages ASP.NET de plus de 1200 ligne (avec code-behind de plus de 100 ligne) ...

Et je me demande comment agir ? Il est trop tard à mon avis pour tout changer, alors vais-je faire les mêmes choses ? Leur dire ce que j'en pense ? Essayer de sensibiliser ? Attendre d'être installer dans l'équipe et voir le fonctionnement de l'équipe et essayer de donner mon point de vue pour les futures dev ?

Bref qu'est ce que vous en pensez ? Si vous avez été confronté à ce genre de chose comment vous avez agis ?

Toute remarque est la bienvenue.

PS : Je pense tt de même que je peux bcp apprendre dans ce genre de contexte ...

[xamage]

La tentation est toujours grande d'améliorer ce qui est fait.
Tu peux toujours essayer d'informer tes supérieurs sur la 'qualité' du code actuel, mais faut pas se leurrer, à moins d'avoir beaucoup d'argent à claquer, la boite pour laquelle tu bosses te donnera pas le feu vert pour casser tout ce qui est déjà fait. Surtout si le projet est d'envergure (ce qui est le cas) et si tout a déjà était testé et recetté.
Dans le cas contraire, et si un certain nombre de tes collegues sont du meme avis que toi, vous pouvez toujours remonter l'info. Mais en admettant qu'on vous dise "ok faites le", n'ayez pas peur de vous en prendre plein la gueule, parce qu'à la moindre difficulté ils vont vous tomber dessus.

Enfin c'est mon avis.

[bpoujol]

Il me semble que c'est a toi de chiffrer la charge de travail.
Dans certains cas, il peut être plus utile de tout reprendre "from scratch" que de comprendre et modifier qqchose de déjà existant.

Dans ton cas, l'archi semble être vraiment "bordélique" il peut être bien de tout re-faire proprement (en pensant à celui qui fera la maintenance aprés toi)

[rad_hass]

Merci pour vos réponses.

Il y a un énorme travaille qui a été fait. Si je leur dis il faut tt refaire, je pense qu'ils vont me rire au nez (surtout que ça fait que mon 4eme jours lol) ...

On m'a dit qu'il serait bien de m'inspirer de l'existant ... Dure lol. Je commence à faire de petite remarque : Ah c bizare que y a pas d'objet pour traiter cela ! Ah y a du Accés aux données ds le site ?

Mais je ne veux ni offencer des personnes, en leur disant comment ils doivent travailler, ni à mettre leur compétences en doutes (sachant qu'eux aussi débarque depuis pas trop longtemps). Bref j'ai le cul entre deux chaises, je ne veux pas critiquer à tt va le travaille des autres, alors que je suis qd même un Junior. Mais qd même y a des choses lol ...

Bref je pense que je vais observer les premiers temps
(ah oui je viens de savoir que y a pas un diagramme de base de données héhé).

[lutecefalco]

Bienvenue dans le monde de l'entreprise où les délais sont bien trop courts pour faire du boulot propre

[rad_hass]

Bienvenue dans le monde de l'entreprise où les délais sont bien trop courts pour faire du boulot propre

souvent les temps sont explosé quand on fait pas du boulot propre (un minimum quoi lol), surtout si on compte la maintenance et les évol ...

[DranDane]

Il me semble que c'est a toi de chiffrer la charge de travail.
Dans certains cas, il peut être plus utile de tout reprendre "from scratch" que de comprendre et modifier qqchose de déjà existant.

Dans ton cas, l'archi semble être vraiment "bordélique" il peut être bien de tout re-faire proprement (en pensant à celui qui fera la maintenance aprés toi)

Oj là je suis pas d'accord du tout. Fausse idée. Mieux vaut refactorer peu à peu que de tout recommencer from scratch. C'est une prise de risques trop importantes.

Il y a bien sur toujours des exception mais on peut se fier à la règle général qu'il vaut mieux refactorer peu à peu que de tout recommencer.

[bpoujol]

Oj là je suis pas d'accord du tout. Fausse idée. Mieux vaut refactorer peu à peu que de tout recommencer from scratch. C'est une prise de risques trop importantes.

Il y a bien sur toujours des exception mais on peut se fier à la règle général qu'il vaut mieux refactorer peu à peu que de tout recommencer.

Le problème est que souvent pour des contraintes de temps tu n'as pas le temps de tout refactorer petit a petit...
Et tu te retrouve rapidement (et tes suivants) avec un projet "batard" bati sur deux méthodes/archi de dev...

Aprés dans le cas présent, peut-être cela est-il mieux vu que le travail effectué est trés important...

[xamage]

Tout a fait d'accord avec DranDane.
En plus, dans la mesure ou tu dois ajouter de 'nouveaux' modules, tu peux profiter de cette occasion pour mettre en place quelques 'best practices', dans le mesure ou ca ne remet pas en cause tout ce qui a déjà été fait, mais que ca ne touche qu'au pan fonctionnel sur lequel tu travailles.

[rad_hass]

Tout a fait d'accord avec DranDane.
En plus, dans la mesure ou tu dois ajouter de 'nouveaux' modules, tu peux profiter de cette occasion pour mettre en place quelques 'best practices', dans le mesure ou ca ne remet pas en cause tout ce qui a déjà été fait, mais que ca ne touche qu'au pan fonctionnel sur lequel tu travailles.

Pas si simple, pas si simple !
Là par exemple je travaille sur une page qui a été entamé (la page a plusieurs onglet et le code de tt les onglets est dans la même page), difficile d'aller dans une autre direction surtout que les page ont le même fonctionnement ... Et le fais qu'il y est très peu de séparation ,mais vraiment très peu, rend ma tâche encore plus compliqué.

Est ce que pour vous mettre les noms des colonnes de la table BDD dans un Enum, est une pratique normale (habituelle) ?