Le travail processé

**black_hole** · 30/07/2016, 16h14

Bonjour
Je viens de faire récemment un entretien une ssii et malgré mon bon profil, l ingénieur d affaire à trouvé à dire sur mon type de travail. Selon lui je n ai pas travaillé suffisamment processé ...

Je ne serais pas reprendre du code car je ne connais pas les procédures pour la reprise de code... je voulais donc savoir quels sont les processus à mettre en place?

**phili_b** · 30/07/2016, 20h13

Bonjour,

Envoyé par black_hole

travaillé suffisamment processé ...

Jamais entendu parler de cette expression. Elle ne veut rien dire.

Envoyé par black_hole

Je ne saurais pas reprendre du code

Je pense qu'il s'agit de "maintenance logicielle".

Envoyé par black_hole

je voulais donc savoir quels sont les processus à mettre en place?

Souvent pour faire débuter les gens, on leur demande de maintenir un logiciel, mais d'autres personnes plus expérimentées doivent les suivre et leur donner des méthodes, ce qui n'est souvent pas le cas. Résultat ça fait du code inmaintenable, avec des grosses erreurs et qui risque de ne pas être valide.

Et donc je soupçonne la ssii de t'accuser de ne pas savoir maintenir du code, par toi même, sans directives, et sans méthodes alors que tu es débutant. Après tout dépend du niveau d'exigence : un débutant peut sans doute s'en sortir sur les cas pas trop compliqués, mais ça n'empêche qu'il faut un contrôle régulier, puisque le processus de maintenance doit être conforme à celui de la société.

**black_hole** · 30/07/2016, 21h11

Maintenir du code et développer du code c est vraiment différent? Ça fait des année que je développe mes applications sans soucis ...

**foetus** · 30/07/2016, 22h21

Envoyé par black_hole

Maintenir du code et développer du code c est vraiment différent?

Tu ne vois pas la différence

Lorsque tu développes tu as ton mot à dire (*).
Et lorsque je dis "mot", cela peut-être sur un détail d'implémentation jusqu"au cahier des charges.

Lorsque tu maintiens tu te prends la tronche sur du code que tu n'as pas codé et que tu es obligé de respecter/ d'utiliser.

* -> quoique je vis ce cas là, mes N+X pensent pour moi et c'est

sauf pour le projet et mon emploi.

**el_slapper** · 30/07/2016, 22h37

Envoyé par black_hole

Maintenir du code et développer du code c est vraiment différent? Ça fait des année que je développe mes applications sans soucis ...

C'est fortement différent. Même si la base est identique. Une fois la base en place, le développeur part de sa page blanche, et ajoute des choses à un ensemble qu'il connait bien, dont il a une carte mentale efficace. Le mainteneur, lui, découvre des choses à chaque ligne, et souvent n'a pas le temps de tout comprendre. Par contre, il doit s'assurer que rien n'a bougé après son passage, à part ce qu'il a spécifiquement modifié.

Il y a aussi une différence de rythme. En maintenance, on saute beaucoup plus du coq à l'âne, spécialement si on est en maintenance à chaud, et on alterne urgences et temps faibles. En projet, on a une plus grande continuité des tâches, et on sait toujours sur quelle base on bosse, et on a un rythme beaucoup plus régulier. Quand on m'a confié une base de code de 1,5 million de lignes à maintenir à chaud(âge moyen : 10 ans), tu penses bien que je n'ai jamais tout maitrisé. Mais il faut savoir faire une macro-cartographie de l'ensemble, pour savoir quoi chercher où. Et tester un peu plus large que la seule modif qu'on vient de faire.....

Maintenant, je ne comprends pas le reproche. Certes, il faut de la méthode pour faire une reprise de code, savoir tester des choses sans avoir le temps de les comprendre(indice : on fait des comparaisons de masse, quand on peut, si c'est du batch). Mais en quoi un "ingénieur d'affaires" peut-il avoir la moindre idée de ce que cela représente? A moins que ce soit un ancien développeur, et même. Il ne peut pas savoir comment tu fais le boulot. Il peut éventuellement noter que tu ne sais pas bien le décrire, mais sur un simple entretien, déterminer que tu bosses mal? Non, si tu rates ton entretien avec moi, la seule chose que je sais, c'est que tu ne m'as pas convaincu(et je ne te recrute pas, mais pour un doute, pas pour une certitude). Pas que tu ne sais pas bosser. En d'autres termes, encore un connard qui attends de toi que tu sortes les mots-clefs magiques à son esprit, et qui te reproches de ne pas les avoir sortis. ça n'est ni le premier, ni le dernier que cette terre aura porté.

Sinon, si il te reproche de ne jamais avoir fait de maintenance, d'accord, mais il faut le dire en termes compréhensibles par un être humain. "Vous n'avez fait que du projet, 80% de nos missions sont en maintenance", ça, c'est un argument recevable. Mais dire de quelqu'un qu'il n'a jamais "processé". Pfut. ça n'a aucun sens. Chaque client, voire chaque département du client, a son propre process, et un bon professionnel l'ingurgite assez vite. C'est même un pré-requis pour faire de la prestation : savoir se mouler dans les méthodes du client. Donc, si il a un process digne de ce nom, le suivre.

**black_hole** · 31/07/2016, 08h25

Merci pour cette réponse.
C est bien ce que j avais cru comprendre, visiblement je ne lui avais pas sorti les mots clefs et que ça l embêté de lire mon dossier de competence pour savoir réellement ce que j ai fait.
Il me disait également que je ne savais pas faire du multithread car je n ai jamais utilisé un truc genre synchrotron ... ça vous dit qqch?

**Uncharted** · 31/07/2016, 08h51

synchrotron

a mon avis c'est le singleton en contexte multi thread, la question basique qui revient souvent en entretien

**black_hole** · 31/07/2016, 15h26

C est dommage parce que je connaissais ça mais j ai pas compris singleton durant l entretien ... Mais bon globalement j avais trop d exigence et je pense au il voulait s imposer.

**Pyramidev** · 31/07/2016, 21h25

Envoyé par black_hole

Il me disait également que je ne savais pas faire du multithread car je n ai jamais utilisé un truc genre synchrotron ... ça vous dit qqch?

Le synchrotron, c'est un accélérateur de particules. Aucun rapport avec le multithread.
Si le recruteur a vraiment dit synchrotron dans le sens singleton synchronisé, alors il est mauvais en français.
Si on s'amusait à faire une contraction de synchronized singleton, cela donnerait plutôt synchroton (qui a un r de moins que synchrotron).

**foetus** · 31/07/2016, 22h03

Envoyé par Pyramidev

Le synchrotron, c'est un accélérateur de particules. Aucun rapport avec le multithread.
Si le recruteur a vraiment dit synchrotron dans le sens singleton synchronisé, alors il est mauvais en français.
Si on s'amusait à faire une contraction de synchronized singleton, cela donnerait plutôt synchroton (qui a un r de moins que synchrotron).

Cela me fait penser à un épisode de Caméra Café

En gros et de souvenirs, le psy de la boite insérait dans sa discussion un mot ~~bidon~~ "un peu compliqué" (mais il le faisait exprès)
Et l'autre personne pour ne pas passer pour un gland, il faisait "comme s'il a compris"

Édit: Saison 1 épisode 129 Valétudinaire (Jean-Claude cherche la définition du mot "valétudinaire".)

Les mots sont pas tous bidons et apparemment le psy ne l'a pas fait exprès

**ed73170** · 31/07/2016, 23h48

Envoyé par el_slapper

C'est fortement différent. Même si la base est identique. Une fois la base en place, le développeur part de sa page blanche, et ajoute des choses à un ensemble qu'il connait bien, dont il a une carte mentale efficace. Le mainteneur, lui, découvre des choses à chaque ligne, et souvent n'a pas le temps de tout comprendre. Par contre, il doit s'assurer que rien n'a bougé après son passage, à part ce qu'il a spécifiquement modifié.

C'est tout à fait cela, et pourtant je vois très souvent des développeurs, même expérimentés, qui confondent les 2. Sur plusieurs missions de maintenance j'ai travaillé avec des gens qui ne pouvaient pas s'empêcher de refaire des parties entières des logiciels à maintenir sous des prétextes divers : "C'est mal écrit", "C'est pas objet", "Je n'y comprends rien alors je vais refaire entièrement cette fonctionnalité", "Je vais vous montrer ce que sait faire un bon développeur", etc. Cela part certainement des meilleures intentions, mais ce n'est pas ce que le client demande. Le résultat est bien entendu que de nouveaux bugs apparaissent même si la demande initiale finit par être implémentée.

Sur ce genre de mission, je ne m'encombre pas d'états d'âme, je ne fais que ce qui est demandé pour que la fonctionnalité réponde au besoin. Alors si on me demande de modifier la couleur d'un bouton, eh bien je cherche l'endroit où cette couleur est définie, je la change et je ne me préoccupe pas du reste du code. Si ensuite le chef me dit : "Ah mais il fallait aussi changer la couleur des autres boutons", je lui réponds : "Ce n'était pas précisé dans la demande initiale, fais-moi en une autre pour faire cette modification." C'est peut-être parfois de la mauvaise foi mais ça fonctionne et le client est content.

**el_slapper** · 01/08/2016, 12h04

Envoyé par ed73170

Snip

Parfois, il faut en profiter pour passer le balai et refaire au propre, ou rajouter des outillages de test, ou factoriser le code, ou que sais-je. Ils n'ont pas forcément tort sur le principe.

Mais on ne peut se le permettre qu'à deux conditions fondamentales :

(1) avoir suffisamment de bouteille sur le code en question pour ne plus le prendre de haut. L'horrible verrue moche qui semble ne servir à rien est généralement en fait une correction d'un bug critique.
(2) avoir mis en place les système de tests complets qui permettent de toucher ici en étant sur qu'on ne va rien casser là. Parce-que bon, si c'est moche, c'est souvent qu'en corrigeant ici on va casser là-bas.....

J'ai refondu pas mal de trucs, mais toujours dans des contextes maitrisés. Soit on m'avait expressément demandé de le faire(et j'ai dû concocter un système de tests complet qui leur manquait depuis toujours, 6 semaines de boulot indispensable et non budgétisé), soit à l'occasion d'un projet majeur ou pas grand chose n'est réutilisable tel quel, soit sur des petits trucs que je commençait à bien connaitre et que je savais tester à fond.

Mais arriver sur un code pourri et le refondre sans se poser de questions? C'est un passeport pour l'enfer. Le seul truc que j'ai fait d'entrée en arrivant dans une mission, c'est rajouter un programme de test pour une bibliothèque de modules. Histoire de (1)pouvoir tester mon nouveau module, et (2)pouvoir m'assurer que je n'avais pas cassé les modules des autres. Mais les refondre? En les connaissant à peine? Au fou!!!

**yolle** · 01/08/2016, 13h03

ben faut juste "processer" le "synchrotron" :-) . A mon avis le commercial doit être une "sacré lumière" :-) :-) ..... pardon, "l'iingénieur d'affaire" .... fantastique, l'info, tout le monde est ingénieur. Tu es juste tombé sur un clown, ne te prends pas la tête.

**Glutinus** · 01/08/2016, 17h04

Salut,

"Travail processé", c'est un bien gros mot pour désigner, heu, je ne sais pas quoi vraiment en fait...
Je ne connais pas ton expérience professionnelle, mais il est possible aussi qu'il t'ait demandé quelle méthodologie tu suivais.

Et celles qui arrivent le plus souvent sont le Cycle en V ou l'Agile.
Et que si tu ne sors pas les bons mots comme il faut : tests unitaires, mise en recette/UAT, tests de recette ou d'UAT avec les utilisateurs, ou homologation, puis tests d'intégration, mise en pré-prod, mise en production, ainsi que des outils de version de configuration, de ticketing, des gestionnaires d'incidents... alors il a peut-être pas été convaincu.

Je dis ça, mais chez un de mes clients, quand j'ai dit que je voulais tester, on m'a regardé avec des soucoupes à la place des yeux "bah c'est développé, faut mettre en prod, non ?", les mecs ils tapaient des lignes de requête SQL, ne les exécutaient même pas et les envoyaient par mail à leurs clients... bref là pour le coup j'ai rien appris niveau méthodo.

Enfin j'extrapole, je ne connais ni ton expérience ni ce qui a dit.

PS : et la blague, après 10 ans d'expérience, je rentre dans une enième SSII, et le commercial me fait un entrainement d'entretien client, OK je suis rouillé, et j'écoute ses conseils qui sont juste... mais on a fait 3 fois l'exercice, et tant que j'ai pas sorti les 50 mots-clés qu'il voulait dans le bon ordre, il voulait refaire l'exercice... bref j'ai claqué la porte :') et j'ai bossé avec un autre commercial qui était tellement nul qu'il m'a laissé faire :-D)

PS : effectivement des fois tu échoues simplement pour un manque de vocabulaire... on m'a déjà demandé de définir le deadlock, je ne savais pas ce que c'était, mais j'ai appris plus tard que c'était le mot anglais pour "interblocage", concept que je connaissais déjà.

**Mat.M** · 02/08/2016, 22h00

Envoyé par el_slapper

Une fois la base en place, le développeur part de sa page blanche

dans un projet informatique,faire du code "from scratch" c.a.d. en partant de rien du tout c'est extrêmement rare maintenant.

Envoyé par el_slapper

Quand on m'a confié une base de code de 1,5 million de lignes à maintenir à chaud(âge moyen : 10 ans)

code spaghetti ,je présume ?

Envoyé par ed73170

Sur plusieurs missions de maintenance j'ai travaillé avec des gens qui ne pouvaient pas s'empêcher de refaire des parties entières des logiciels à maintenir sous des prétextes divers : "C'est mal écrit", "C'est pas objet", "Je n'y comprends rien alors je vais refaire entièrement cette fonctionnalité",

je fais partie de ceux-là...

parfois sur un projet on est amené à réecrire des parties du code, à le remodeler pour y perpétuer des évolutions

**Uncharted** · 02/08/2016, 23h07

pour en revenir au sujet si ton commercial a eu des doutes sur ton expérience professionnel c'est sans doute parce que tu es allé trop dans la technique je supposes ?

ne pas oublier qu'un entretien est un bon exercice de synthèse
cela ne se résume pas qu'a faire un inventaire de ses réalisations/compétences techniques, il faut savoir l'adapter/structurer suivant ton interlocuteur
tu peux te retrouver devant une RH qui ne comprendra pas grand chose et qui va évaluer ta perso, un pure techos qui va vouloir plutôt évaluer ton savoir faire, un manager qui aura le soucis en plus de savoir si tu sauras t'adapter au contexte de l'entreprise (methodo, process etc) et si tu sais faire autre chose que du code (lead, support, connaissances fonctionnels, etc)

y a bien une chose que j'ai tiré des SSII c'est de savoir me présenter et vendre mon cv (méthode de l'entonnoir etc)

un exemple qui me revient en tête j'ai fait passer un entretien a un dev récemment, je lui demande de me décrire son expérience: il était incapable de me présenter son expérience de manière structurée
c'était du genre j'ai fait euhhh ... rigolade et puis j'ai fait ca euhh , ah bah tiens j'ai fait ca ahah
je lui demande sur quelle version de la plateforme il bossait et d'autres questions c'était approximatif et assez flou

au final même si je ne doute pas de ses réalisations mais j'en ai eu une impression mitigée
et du coup j'aurais plutôt tendance a prendre quelqu'un qui m'aurait fait une meilleure présentation à compétences égales

**el_slapper** · 03/08/2016, 10h16

Envoyé par Mat.M

dans un projet informatique,faire du code "from scratch" c.a.d. en partant de rien du tout c'est extrêmement rare maintenant.

Mais en projet, on est au point de départ(qui n'est pas une page blanche, on est bien d'accord), et puis on avance régulièrement vers un but fixé. Au moins sur le composant, on a de la page blanche. En maintenance, que dalle, et c'est de la réaction bien plus que de l'action réfléchie.

Envoyé par Mat.M

code spaghetti ,je présume ?

Même pas. Plus des kilomètres de code façon script linéaire, presque sans procédures, avec des redites partout. Un véritable chapelet. Du code qui se lit comme un livre, du début à la fin, sans saut. Au final, c'est plus digeste que du code spaghetti, mais c'est quand même peu optimisé pour des maintenances massives(euphémisme). Par contre, les effets de bord sont plus rares(mais on en a quand même parfois)

Envoyé par Mat.M

je fais partie de ceux-là...

parfois sur un projet on est amené à réécrire des parties du code, à le remodeler pour y perpétuer des évolutions

Le risque, c'est de mépriser le code d'avant. Or, généralement, le code d'avant, aussi pourri soit-il, marche. Et doit être respecté pour ça. Après, oui, on peut mettre un ancien code à la poubelle..... une fois qu'on est sur de ne rien perdre de ses années de peaufinage.

**Shirraz** · 03/08/2016, 14h14

Envoyé par Glutinus

PS : et la blague, après 10 ans d'expérience, je rentre dans une enième SSII, et le commercial me fait un entrainement d'entretien client, OK je suis rouillé, et j'écoute ses conseils qui sont juste... mais on a fait 3 fois l'exercice, et tant que j'ai pas sorti les 50 mots-clés qu'il voulait dans le bon ordre, il voulait refaire l'exercice... bref j'ai claqué la porte :') et j'ai bossé avec un autre commercial qui était tellement nul qu'il m'a laissé faire :-D)

A un entretien on m'a demandé de définir ce qu'est une interface... j'ai expliqué en long en large et en travers de manière très juste et e haustive ce que c'est, à quoi ca sert, dans quels cas et comment... puis il m'a parlé de fourchette, de quatre dents généralement en métal servant à piquer des aliments pour se nourrir tout ca tout ça...

pour enfin me pondre " je voulais juste que vous disiez le mot "contrat", comme dans mon exemple, avec fourchette", pour vérifier que vous saviez bien ce que c'est...