Transition école -> travail

[Pill_S]

Bonsoir à tous,

J'ai terminé mes études il y a environ 3 mois. J'ai toujours appris certaines règles que je considère désormais comme étant les fondements d'un "bon" code. Par exemple, commenter un code. Ne pas utiliser de variables globales. Utiliser des identificateurs porteurs de sens. Favoriser l'encapsulation, la clarté du code, etc...

J'ai trouvé du travail dans une entreprise. Le seul programmeur autre que moi est le patron. Il a appris à la vieille école, ne commente pas son code, utilise un maximum de variable globales (plusieurs pages par programmes !), et donne des noms loufoques à ses identifiants (Fen1225, VpxBidon, ...). C'est tout juste pas truffé de "goto" !!

Et maintenant, je me retrouve à coder dans un environnement vraiment complexe, alors que j'ai toujours estimé que la programmation était un art simple, si l'on s'y prend bien dès le début.... Du coup, ma productivité est largement inférieure à ce que j'arrivais à fournir durant mes études... Je passe des heures sur quelques lignes, tellement elles sont complexes... Et je suis franchement frustré et démotivé... J'aimerais arriver à lui prouver que je suis un bon programmeur, mais nos définitions d'un bon programmeur semblent être 'achement différentes......


Bref, tout ça pour en venir à ma question: comment s'est passée votre transition entre le monde scolaire et le monde réel ? Avez-vous ressenti les mêmes problèmes que moi ?

Tous les commentaires sont bienvenus

[Piotrek]

Même en étant autodidacte j'ai eu la même impression de bidouille pour mon premier travail.

J'ai essaye d'évangeliser, en tout bien tout honneur mon boss de l'époque, je me suis fait licencier au bout d'un an...

Si t'as de bon rapports, il faut y aller par doses homépatiques. Si a un moment tu peux développer quelque chose de nouveau, vas-y a ta manière sans lui mettre la puce a l'oreille, en commentant, en fesant ca proprement et explique-lui ensuite comment marche le tout sans dire que ta facon est la meilleure: il faut que ton patron le comprenne de lui-même

Si il est intelligent, il te laissera faire en pensant que la nouvelle génération est forcement plus a la pointe

[ArHacKnIdE]

Il faut arriver à lui démontrer que c'est plus facile

[Hephaistos007]

Le génie logiciel n'était pas enseigné à son époque. Mais la nouvelle génération, mieux formée, arrive...

[Piotrek]

Oui mais surtout ne rien dire: lui laisser comprendre pour qu'il vous fasse confiance, apprenne de vous

C'est pas de la diplomatie qu'il faut, c'est de la furtivité sinon il y a de très fortes chances qu'il le prenne pour une critique personnelle (mon ancien patron était vraiement sympa, cela n'a pas empeché le problème de s'envenimer)

[Pill_S]

Oui, c'est toute la problèmatique...

Comment un gars sans expérience peut essayer d'instruire un type qui code depuis 20 ans toute la journée...

N'empêche que je passe pour un c**, il me faut 3 plombes rien que pour retrouver la ligne qui m'intéresse... Si j'ai besoin d'une info, je dois analyser des dizaines de lignes, pour finalement utiliser des variables qui tombent de nul part et qui sont modifiées par certaines procédures...

Je m'arrache vraiment les cheveux ! Y'a-t-il beaucoup d'entreprises qui travaille comme cela ou bien ai-je trouvé la seule parmis des milions ?

Ce serait un peu comme gagner à l'euromilion, mais dans l'autre sens...

[ArHacKnIdE]

Tu devrais jouer à l'EuroMillion

[Cyr1c]

Envoyé par Pill_S

Oui, c'est toute la problèmatique...

Comment un gars sans expérience peut essayer d'instruire un type qui code depuis 20 ans toute la journée...

N'empêche que je passe pour un c**, il me faut 3 plombes rien que pour retrouver la ligne qui m'intéresse... Si j'ai besoin d'une info, je dois analyser des dizaines de lignes, pour finalement utiliser des variables qui tombent de nul part et qui sont modifiées par certaines procédures...

Je m'arrache vraiment les cheveux ! Y'a-t-il beaucoup d'entreprises qui travaille comme cela ou bien ai-je trouvé la seule parmis des milions ?

Ce serait un peu comme gagner à l'euromilion, mais dans l'autre sens...

C'est pour éviter ce genre de choses que les normes ont été introduites (CMM-I et consoeurs). Seulement, on travaille dans un métier qui est encore très jeune et l'existant est une contrainte très forte encore aujourd'hui. Et cet existant date d'une époque ou d'une part le génie logiciel et l'assurance qualité n'était pas aussi présente qu'aujourd'hui (et encore moins que demain) et d'autres part, on est un métier assez bizarre où même aujourd'hui, un ingénieur ou un analyste programmeur code parfois comme ses pieds en toute impunité (du fait que l'assurance qualité n'est pas encore assez répandue dans notre métier).

Je dirais que pour ce qui est de la qualité du code, celle ci dépend souvent de la complexité, le cout et la taille de projet, plus ces variables sont importantes, plus le code sera de qualité car il s'agira de ne pas planter le projet. Pour des petits projets, j'ai encore eu l'occasion de voir des gars programmer à l'arrache.

Donc non, tu n'es pas une exception, mais t'es quand même dans une minorité de cas (petite boite, faible culture technologique et qui repose sur une seule personne semble t'il). Si vraiment ca te démotive, pense peut être à changer de taff

[WolffN]

salut

tu sais il a aussi et surtout des histoires de couts et de delais

si tu as deux jours pour boucler un projet de deux semaines ben forcement tu traces ...

tu traces parce qu'on te demande de faire un truc "rapide" qui marche et qui fait quelque chose de " très simple"

(et aussi parceque ton chef te fait subtilement remarquer que tu as d'autres client plus gros et plus important qui sont donc prioritaire)

il faut ensuite voir l'évolution du projet dans le temps

exemple

T0

au depart tu fais un petit exe d'interface bidon (delai estimé 2-3 jours, sans autres infos que celle de ton chef) -> délai realisation 5 jours (chef pas content mais programmation correcte)

T1 install

T2 = T1 + ~ 2-3 jours

exe qui marche mais ne fait pas ce que le client demande (re analyse tres rapide au tel avec le client qui demande une legere modif)

demande confirmation a ton superieur -> reponse "c'est facile tu le modifie juste comme ça" (magouille N°1)

T3 = T2 + quelques semaines

re tel client demande legere modif a faire en urgence (suite a modif parametrage ou maj logiciel source)-> trajet idem (magouille N°2)

-> facturation modif

le cycle T3 est répété un certain nombre de fois

T4

tel client nouvelle demande de modif (la tu commence à comprendre ce que souhaite le client et le logiciel commence a devenir complexe)

le client commence à utilisé le logiciel et ne veux plus reinvestir dans un nouveau logiciel donc demande modif -> +ou- magouille car ton chef ne veux pas t'autoriser à re ecrire le logiciel car il ne sera pas payer

au bout de 1 ans -> ton code passe de programme lisible à programme nettement moins lisible

[lakitrid]

Personnelement je suis arrivé sur un projet ou c'est out l'inverse.
Un squelette de programme unique (je précise c'est du Cobol)
La norme ISO 9001 à suivre avec la tonne de document à la clé.
Genre limite 1 page de doc pour quelques lignes de codes. Enfin là je compte les specs, expression de besoin, documentation du code, bilan de test, etc...
Au final un processus de dev bien ficellé, très contraignant mais avec des délai rationnels, aucune impasse sur les tests et la qualité du code.

Comme quoi on peut trouver de tout.

[hugo123]

Perso j'ai eu droit aux deux. Un projet très bien ficelé, avec des normes très fortes etc... Un autre avec un chef de projet ressemblant un peu a celui décrit plus haut mais moins caricatural quand même).
Mais ca dépend pas de la boite selon moi, les deux étaient grosses et le projet était important. (Le second projet c'était la société générale)
J'aurais difficilement de bons conseils car je n'ai pas bien su moi même gérer le problème avec mon chef de l'époque.
J'étais la pour faire du conseil technique mais quand t'as 25 ans et que le type bosse depuis 30 ans, il écoute mais fait a son idée. Dans l'ensemble c'était une expérience un peu désagréable.
Bonne chance pour la suite, en espérant que tu trouves d'autres projets plus normalisés. Mais ca reste une expérience bonne a prendre et instructive selon moi.

[nako]

Envoyé par Pill_S

Y'a-t-il beaucoup d'entreprises qui travaille comme cela ou bien ai-je trouvé la seule parmis des milions ?

Beaucoup d'entreprise travaillent comme ça, surtout quand un logiciel est utilisé depuis longtemps, qu'il a subit les vagues successives de plusieurs développeurs/chefs de projet, qui avaient chacun sa vision de la chose.
A l'école, on apprend la pratique, en entreprise, on découvre la réalité.
On trouve souvent un fossée entre les 2 !
Je bosse actuellement dans une équipe avec un chef de projet qui a toutes les notions de Génie Logiciel, pas de problème.
Mais on bosse sur un projet qui a une vraie histoire, avec des parties de codes bien pensée, des verrues toutes pourries, etc ...
Les contraintes indutrielles ne nous permettent pas de refaire l'architecture et de partir sur des bases saines.
Par contre, dès qu'on fait quelque chose de nouveau, on essaie de le faire proprement.
Mais ne te fais pas d'illusion, c'est comme ça dans beaucoup de boites.
Il n'y a qu'à l'école où tu pars de zéro et où tu fais un truc super propre.
(qui sera soit dit en passant super propre pour toi mais peut-être pas pour un autre.)
Courage.
a+

[ludovic.fernandez]

Bonjour,

Il existe aussi l'art et la manière de lire du code et on ne l'apprend pas à l'école (comme on ne forme pas forcément de bons développeurs). Chacun possède son style de rédaction et bien heureusement.

Le code n'est pas statique mais dynamique, par conséquent, lorsque tu ne peux pas photographier d'un oeil le processus pour cause de complexité de l'implémentation, tu peux forcément le faire par debugging.

Apprendre à débugger, c'est apprendre à s'adapter. Reste ensuite, à établir ses propres diagrammes ou autres modelisations (un langage commun).

Ludovic

[Kenji]

C'est pas ce qu'on reproche à MS?
Un gros pavé de lignes non commentées

Effectivement çà doit pas être simple de lui faire entendre raison,la meilleure façon je dirais,c'est d'attendre un projet que tu dois réaliser seul et de bien l'avancer pour lui montrer par la suite que les commentaires et les consignes de nommage sont pas mal

[Pill_S]

Merci pour les commentaires continuez à poster

Finalement, je vais continuer la stratégie actuelle, à savoir me dépatouiller de mon mieux avec l'existant sans trop critiquer: c'est la seule chose intelligente que je puisse faire. Espérons que je n'écrive pas trop de bugs !

A la première occasion, je lui fait un super truc modélisé avec UML, complètement Objet, bourré de commentaires et avec une doc en bêton.

Comme ça au moins je laisserai ma marque dans son entreprise !

[Hephaistos007]

Envoyé par Kenji

C'est pas ce qu'on reproche à MS?
Un gros pavé de lignes non commentées

Pourquoi tu dis ca ? tu as accès aux codes sources de MS toi ?