Maintenance corrective pour un master

[Kihmé Xs]

Bonjour à tous,

Je fais actuellement mon stage de fin d'année (M1) dans une SSII. J'ai suivit un cursus d'analyste développeur. Ce que j'aime par dessus tout et là où je me sens le plus à l'aise c'est d'analyser, modéliser et développer un besoin. Chaque fois je le prend comme un défis et ne m'autorise qu'à délivrer la meilleure solution possible. Durant ce stage je faisais de l'outillage pour une TMA. Sous condition que le stage se passe bien j'avais la possibilité de continuer avec cette SSII pour un contrat pro (temps partiel en entreprise sur 6 mois puis temps plein sur 6 mois également). On m'a proposer ce contrat pro pour un poste de maintenance corrective. J'ai fais quelques defects pour l'équipe pour dépanner et faire des petites corrections dans des bouts de code pendant 10 min puis enchainer 5 jours de conception de jeu de test puis passer les tests ça m'a profondément ennuyé.

J'ai peur que de la maintenance corrective ne m'aide pas à monter en compétence technique alors que je cherche à pouvoir me positionner en tant que détendeur d'une véritable expertise technique sur un moyen terme.

Du coup je me pose plein de question, accepter ce contrat pro ne serait il pas un risque pour mon objectif à moyen terme? Faire du testing/debug, car c'est bien ça que sous entend maintenance corrective, est il un passage obligatoire même pour un ingénieur, quitte à prendre le risque de perdre en compétence technique?

Mes collègues m'ont laissé entendre que d'accepter ce genre de poste au vue de mon profil et de mes attentes de carrière n'était peut être pas une bonne idée. J'ai besoin d'un maximum d'avis pour m'aider dans ma prise de décision, tous les avis me seront utiles.

Merci d'avance

[HerQuLe]

All code is crap

http://www.makinggoodsoftware.com/20...are-developer/
http://markos.gaivo.net/blog/?p=253
http://www.daltonlp.com/view/491



Dis toi que la maintenance corrective et évolutive c'est 80% du boulot d'un informaticien... il est vraiment rare, dans la vie de tous les jours qu'on ait a coder des choses vraiment nouvelles (à moins que tu ne fasses des petits sites web dans une webagency...)


Pourquoi je parle de "all code is crap"? parce que le tiens aussi!
Du coup tu trouves ça normal de vouloir faire les trucs les plus sympas et de laisser les autres, dans 1 ou 2 ans, devoir debugger les lignes merdiques que tu as pondu?
Sans compter que si tu ne fais que tu nouveau code, tu ne remet jamais réellement en question ta manière de coder.




Avoir une expérience de la TMA est pour moi quelque chose d'indispensable pour tout bon développeur qui se respecte, pour la simple et bonne raison que tu apprends en lisant le code des autres...

Parfois il y aura de belles choses, tu te diras "sympa je vais m'en souvenir la prochaine fois que je code, bon il y était presque y a juste un tout petit bug".

Parfois tu verras quelqu'un faire quelque chose que tu aurais fais de la même manière, et tu te diras "oulaaaa ah oui il faut vraiment pas faire comme ca en fait "

Avec le temps et l'expérience, tu sauras quels sont les patterns et anti-patterns en fonction des situations, et tu te forgera un style inspiré de ceux que tu auras lu.



La vision que tu n'as pas forcément à l'école c'est que:
C'est facile d'écrire du code qui fait ce qu'on lui demande de faire, à un moment donné
Ce qui est difficile est de faire en sorte que ton code marche mais qu'en plus les autres puissent le lire et le faire évoluer facilement






Tu es encore à l'école et tu as probablement une vision du monde de l'entreprise un peu limitée... je ne sais pas ce que tu veux faire, quelles technos etc, mais dis toi que si tu bosses sur des applications d'entreprise (ex JEE / .Net / Cobol ...), la majorité du boulot sera de faire en sorte que des applications vieilles de 2, 5, 10 ou 20 ans tournent, et tournent bien.

Je trouve que commencer sa carrière sur un gros projet d'entreprise un peu vieux (mais pas trop obsolète non plus niveau technos) par un peu de TMA ne fait de mal à personne (pas trop longtemps hein, 1 an c'est bien).
C'est pas forcement ce qui fait progresser le plus sur le framework X ou Y, mais tu apprends quand même beaucoup de choses.

Et puis toutes les anomalies ne sont pas forcement dues à un petit bout de code métier pourri:
- parfois il y a des anomalies métier très complexes à résoudre: tu développes tes capacités d'analyse)
- parfois il y a des anomalies techniques très complexes à résoudre (comportement différent selon le hardware, deadlocks....)
- parfois ca touchera l'usage fait du framework X (la tu peux monter en compétences dessus, et n'hésites pas à prendre ton temps pour te former)
- parfois tu vas devoir faire des gros refactorings, et du coup tu vas pouvoir écrire un peu plus de code que d'habitude... (mais il faut se souvenir de la règle: "si ça a été fait de cette manière, c'est qu'il y a probablement une raison" donc ne pas se lancer tête baissée sans un minimum d'analyse)





Qu'est ce que tu appelles "compétences techniques" au juste?

Tu sais que les experts en tests de charge, intégration continue ou tests automatisés sont assez technique en plus d'être recherchés et bien payés?

[Kihmé Xs]

merci de ton avis.

Pour ce qui est du code et de sa maintenabilité tout ce que tu dis sont des choses dont je suis bien conscient et c'est bien intégré dans mon esprit, l'école nous y a préparé et mes petites expériences me l'ont bien démontré.

Ce que j'entend par compétences techniques c'est la maîtrise des langages. Mes collègues m'ont dit que eux ne sont pas vraiment des développeurs, ils ne maîtrisent pas forcément les langages qu'ils utilisent, ils savent les lire et opère les corrections qu'on leur demande, et effectivement, sur les defects que j'ai pu faire, des bases d'algorithmies suffisent à faire le travail pas besoin d'avoir de réelles compétences plus poussées. Du coup j'ai peur (car si j'ai demandé vos avis, c'est que j'ai peur de ne pas bien m'orienter) de ne pas avoir une réelle montée en compétence en tant que développeur. Aucun doute sur le fait qu'en quelques mois je maîtriserais l'applicatif, mais est ce vraiment une compétence qui à moyen terme va me servir pour pouvoir me positionner sur des projets plus intéressants?

Un de mes collègues qui est intégrateur m'a dit que ce n'est pas sur ce genre de projet que je progresserai techniquement, que en bossant en tant qu'intégrateur ça serait le cas, mais certainement pas à faire les defects. C'est ce qui m'a mit le doute. Durant notre conversation il a rajouté, que si je continuais à faire de l'outillage pour cette TMA je progresserais certainement plus mais que de faire des defects ne m'aiderait pas forcément. Du coup je suis perdu.

A les entendre parler, ils n'ont pas une vision très haute du poste de développeur sur les defects. L'un deux m'a dit "nous on est des brêles, et si on en était pas on ne serait pas là à faire ça." Sur le moment je me suis dis "ah mince, il serait dommage d'avoir pousser mes études au maximum en prenant énormément sur moi pour me retrouver à bosser en tant que "brêle".

[phili_b]

Il est indispensable de passer par la case maintenance d'abord pour apprendre et ensuite, comme HerQuLe le dit, la majorité du boulot c'est de la maintenance.


N'empêche que si tu veux évoluer il faut te trouver des missions et/ou des clients qui ont aussi assez rapidement des projets de A à Z. C'est à dire que tu feras peut-être de la maintenance 70% de ton temps, mais tu feras pendant 30% de temps des nouveaux projets ou à défaut des nouvelles fonctionnalités qui seront plus intéressantes et te feront progresser vers la modélisation et la conception.

Effectivement certains postes ou missions risquent de t'enfermer dans un type de boulot (voir là et là).

Il faut de tout pour faire un monde et certaines personnes préfèrent les tests, d'autres la maintenance, d'autres n'aiment pas développer et veulent rapidement faire de la conception ou du fonctionnel: le danger est d'être conduit là où on ne veut pas. ça dépend aussi de sa propre évolution: à un moment on préfère développer et c'est qu'ensuite qu'on veut faire de la conception et du fonctionnel.

En tout cas à la lecture de ton premier message sur ce topic, et de ce que je viens de te dire, je ne suis pas sûr que ce contrat pro te convienne car en TMA tu risques de faire uniquement ou presque de la maintenance, et ça va être dur après d'enlever cette étiquette. Et si tu acceptes il faudra très vite demander à changer si ça ne te plait pas. Par contre l'avantage c'est que tu n'auras pas de déplacements contrairement à beaucoup de boulot de ssii.

[Kihmé Xs]

Envoyé par phili_b

en TMA tu risques de faire uniquement ou presque de la maintenance, et ça va être dur après d'enlever cette étiquette.

C'est ce qui m'inquiète un peu. Mais est ce qu'en 1 an (dont 6 mois à temps partiel) on se voit coller une étiquette?

Envoyé par phili_b

Il est indispensable de passer par la case maintenance d'abord pour apprendre et ensuite, comme HerQuLe le dit, la majorité du boulot c'est de la maintenance.

Ok, j'avais juste peur de ne pas apprendre assez en technique, visiblement j'avais tord.

[el_slapper]

De toutes façons, il est pas mal de projets ou l'aspect technique est assez limité aussi. Je suis en train de sortir d'un projet de 6 mois, qui, bien qu'il m'aie beaucoup appris niveau fonctionnel, m'a appris 0 niveau technique(bon, en même temps, je suis pas débutant).

All Code is crap. Le mien aussi. Je vais avoir le "plaisir" de le maintenir les 18 prochains mois, et toute erreur que j'aurais pu commettre va se retourner contre moi. Boum. . C'est comme ça qu'on apprend. J'ose prétendre que mon code est plus lisible qu'il y a 10 ans quand j'ai commençé(oups, 11, en fait). Mais ça reste de la merde, comme 100% du code sur cet planète. Et si moi j'ai la charge de le garder en état de marche, y compris quand l'appli en amont le bombarde de merdasse(et je reste poli), alors (1)ça m'oblige à faire assez honnête du premier coup et (2)j'aurais tout de suite en pleine tête chacune de mes erreurs.

Pour ça, une équipe de maintenance qui fait des vraies évolutions de temps en temps, c'est très interessant.

[fregolo52]

Envoyé par Kihmé Xs

C'est ce qui m'inquiète un peu. Mais est ce qu'en 1 an (dont 6 mois à temps partiel) on se voit coller une étiquette?

Fuis, si tu ne fais pas de maintenance évolutive !!!

Plus sérieusement, ca fait 1.5ans que je fais de la maintenance corrective (uniquement), ça se résume à 90% du temps à comprendre/analyser/tester les bugs et les derniers 10% à du dév, entre autre.

C'est super enrichissant, mais faut pas y rester longtemps (1an max). Sinon, comme tu le dis, tu auras une méga étiquette dans le dos.

J'ai un ami qui a fait 4ans de dév, puis ces 3 dernières années à l'IVQ. Et il traîne cette dernière sur le dos malgré sa plus grosse expérience en dév.

[Kihmé Xs]

Bonjour,

Je me disais que je pouvais faire un bilan, on est 8 mois plus tard. J'ai accepté le contrat pro pour ce poste.

J'ai vraiment l'impression d'être une brêle, je suis entouré que de collègues expérimentés, par rapport à eux je ne tiens pas les délais. C'est cependant un moteur pour moi, je ne me laisse quasiment aucun moment de répit.

Mon chef de projet m'envoie, évolution ou correction indifféremment. J'ai du passer une majorité de mon temps sur du PL/SQL et le reste réparti entre du Java, du VB. Finalement j'ai vraiment l'impression de commencer à prendre de l'expérience sur ces trois langages, vu le temps que je passe à faire de la recherche pour réaliser ce que je fais et/ou à lire l'existant.

Il est clair que ce n'est pas spécialement passionnant, je suis assez loin des défits de créativité, d’algorithmie ou de conceptualisation que j'affectionne. Mais chaque journée passée, me fait rajouter quelque chose à ma liste des points qui m'aideront à mieux développer des projets perso. Car j'ai l'impression que pour développer en état de jouissance et d'euphorie il faut s'alimenter soit même en projet perso, et que du coup il faut voir le travail comme un moyen d'acquisition de compétence.

Pour le moment je ne regrette pas, les start ups me font envie, les organisations internationales aussi (EU, OTAN), mais je repousse tout ça pour dans un second temps. La maintenance corrective et évolutive, ça permet une bonne entrée je pense. Après est ce que ça permet de préparer une bonne carrière??? Aucune idée, on en reparlera dans 20 ans.

[micka132]

Je pense pas qu'il y ai un seul développeur qui n'ai jamais fait de maintenance!
Perso j'ai fait 2 ans d'alternance c'etait du from Scratch, ensuite j'ai intégré une SSII, pendant 6 mois j'ai fait 2 missions from Scratch, et la depuis 3 semaine ben c'est de la TMA...J'ai donc finis par arriver sur de la TMA!

C'est vrai que c'est pas hyper passionant techniquement parceque ce sont de vieux projets .
En même temps, avec ce que je vois maintenant je peux repenser à ma première experience qui était du Silverlight, et me dire que mon ancien chef était vraiment un gros **** qui voulait me faire coder en silverlight exactement comme en VB6 et qui comprenait pas le soucis[...] Les technos ont évolué et il est toujours bon de voir ce qui se faisait avant, ne serait-ce que pour expliquer à un vieux chef borné les différences avec aujourd'hui et donc éviter de rentrer dans le mur.

Apres mon but c'est de devenir "expert" (un vrai pas au sens SSII) .net/ architecte, et c'est toujours bon de voir de multitude de projet et d'analyser les solutions mise en place, afin d’acquérir des réflexes.
Bref en conclusion la TMA ca me saoul si c'est pour des vieux projets mais il faut en manger un peu, par contre de la TMA sur un projet qui vient de sortir avec tout un tas de truc "moderne", là ca doit être plus sympas!

[deathness]

Envoyé par Kihmé Xs

Bonjour,

Je me disais que je pouvais faire un bilan, on est 8 mois plus tard. J'ai accepté le contrat pro pour ce poste.

J'ai vraiment l'impression d'être une brêle, je suis entouré que de collègues expérimentés, par rapport à eux je ne tiens pas les délais. C'est cependant un moteur pour moi, je ne me laisse quasiment aucun moment de répit.

Mon chef de projet m'envoie, évolution ou correction indifféremment. J'ai du passer une majorité de mon temps sur du PL/SQL et le reste réparti entre du Java, du VB. Finalement j'ai vraiment l'impression de commencer à prendre de l'expérience sur ces trois langages, vu le temps que je passe à faire de la recherche pour réaliser ce que je fais et/ou à lire l'existant.

Il est clair que ce n'est pas spécialement passionnant, je suis assez loin des défits de créativité, d’algorithmie ou de conceptualisation que j'affectionne. Mais chaque journée passée, me fait rajouter quelque chose à ma liste des points qui m'aideront à mieux développer des projets perso. Car j'ai l'impression que pour développer en état de jouissance et d'euphorie il faut s'alimenter soit même en projet perso, et que du coup il faut voir le travail comme un moyen d'acquisition de compétence.

Pour le moment je ne regrette pas, les start ups me font envie, les organisations internationales aussi (EU, OTAN), mais je repousse tout ça pour dans un second temps. La maintenance corrective et évolutive, ça permet une bonne entrée je pense. Après est ce que ça permet de préparer une bonne carrière??? Aucune idée, on en reparlera dans 20 ans.

C'est sympa pour un début, mais si tu veux plus, n'y reste pas trop longtemps, et recherche dans une autre boite un projet de dev.
Personnellement je ne suis jamais passé par là, et depuis la fin de mes études je travaille spécifiquement dans de la R&D sur différentes boites.
Pour moi qui adore l'algorithmie et l'architecture c'est génial.
Je te conseille donc de chercher dans la R&D si tu veux avoir des défis intéressants.

[Louis-Guillaume Morand]

Tout le monde y passe un jour où l'autre. j'ai fait développeur puis technical lead sur des projets et je suis fortement monté en expertise ce qui m'a permis de travailler pour microsoft où maintenant j'accompagne les développeurs déjà experts des SSII. Et aujourd'hui je fais quoi? je corrige leur code et fait de la TMA.
Recherche de fuite mémoire, recherche de failles de sécurité, analyse du code et post-mortem pour améliorer les futurs release, crois-moi, la TMA n'est pas forcément un truc d'indien bas niveau. Certes, cela met bien souvent de côté le côté modélisation mais bon le reste, à toi de transformer ton rôle pour qu'il te fasse apprendre, notamment en faisant des retours aux développeurs. Dans mon cas de "debuggeur TMA" une plus-value non pas en allant pisser du code avec eux, mais en pissant du code derrière eux et en synthétisant les problèmes et les méthodes à utiliser pour ne pas réitérer le problème.

Tu es jeune, tu as le temps de progresser ;-) prend un rôle et restes-y tant que tu y as à apprendre. après, transforme-le ou bouge.


Comme le conseille deathness, la R&D pourrait te plaire dans le futur mais d'un avis perso, chez chaque grand compte où j'interviens, les modèles R&D sont pensés avec une vision trop serrée car les archi sont tellement loin du besoin business qu'ils ont le nez dans l'archi standard et si ton besoin s'en écarte d'un pouce, t'es coincé. donc attention à la R&D, les mecs qui y sont depuis trop longtemps sont trop déconnectés et quand tu les mets sur un gros projet, type progiciel, tu vois des lacunes (meme si techniquement parlant la qualité est là, mais ne correspond pas à l'évolutivité et l'agilité d'un projet)