salut
 
Voici mon cas, issue d'une filiere de chimie j'ai suivi une formation d'un an , en developpement dans les NTIC.
J'avoue avoir trouvé du job facilement et rapidement (pas aux bonnes conditions mais bref.....).
Me voila devant mon clavier du matin au soir, à faire de l'asp du php du sql etc etc...
Biensur quand je demarre un truc, j'ai plein de bug, je corrige je modifie, je rajoute des bugs....
Le responsable me dit finalement il faudrait ajouter ceci cela...du coup mes fonctions sont plus adaptés je recommence rebugs remodif.........
Fin bref je m'arrache les cheveux assez souvent.
 
Voici ma question, vous qui developpez depuis un certain temps, est ce que je dois m'attendre à galerer comme ça tout le temps......
et si non la phase de transition c'est quoi 1 moi, 10 ans.....

Pourquoi penses-tu que l'on te paye

Ca depend de ta maniere de developper. Les erreurs que tu fais actuellement en developpant des trucs trop specifiques ne vont durer qu'un moment.
Apres, tu en auras marre, et tu te feras tes petites bibliotheques de fonctions qui te resserviront tout le temps.
 
Maintenant, en ce qui concerne les desirs changeants des responsables, helas, c'est la loi du marche qui impose ca, souvent pour aboutir a une version finale, il y a beaucoup de dechets, de travail qu'on est oblige d'abandonner en cours de route...

Les bugs c'est ta vie !

avant de commencer a taper ton code....fais une analyse de ton probleme, sans ca, tu seras jamais capable de faire un bon programme facilement updatable ! L'annalyse y'a que ca de vrai ;o)...tout sur suport papier ...comme ca tu es sur de pas avoir d'erreurs d'algo

Ben moi, quand j'ai des problèmes, je vire tout, je mets des débug sur les variables pour voir si c'est OK.
 
Comme ça, si ça marche pas, je trouve très vite l'erreur.
 
Ensuite, je recolle petit à petit tout ce que j'avais viré.
 
Aussi, je décompose le plus possible les différentes tâches à faire (en créant des fonctions en bibliothèque comme tgrx) de sorte que mon code principal soit facilement lisible. Ca me permets aussi de lever des exceptions sur ces fonctions.
 
Voilà, c'est comme ça que je fais chez moi

Ha le debug ...  
 
 
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
TYPE...
 
 
         
 
A+

 
tout à fait d'accord : seulement 10% des développeurs sont capables de coder direct, le problème c'est que 90% des développeurs sont persuadés qu'ils font partie des 10%

bonne analyse + découpe en modules = bon programme  

imhotep03 a écrit a écrit : bonne analyse + découpe en modules = bon programme

Oui, à condition de ne pas implémenter n'importe comment...
En particulier, respecter la règle d'or : ne jamais penser à l'optimisation sauf une fois que le programme marche.

y en qui n'y pense pas de toute façon
Mais c'est clair, c'est une règle d'or

imhotep03 a écrit a écrit : y en qui n'y pense pas de toute façon Mais c'est clair, c'est une règle d'or

Pour ceux-là, je ne me fais pas trop de souci. Je pense plutôt à ceux qui pensent optimisation tout au long du processus de développement, et qui sacrifient la lisibilité et la qualité de leur code à une hypothétique optimisation locale, dont la plupart du temps, ils n'ont aucune idée de l'effet réel (beaucoup d'optimisations présupposées ralentissent en fait le code... parce que le compilateur ne sait plus optimiser dans ce cas ! Et ralentissent aussi le processus de développement, en augmentant le nombre de bugs)

Moi, je préfère la sécurité : j'alloue toute la mémoire du système comme ça je diminue le risque de SegFault  

pareil, et pis, je desalloue jamais la memoire, comme ca, hop, on peut ecrire partout sans erreur.
Le delete (ou free) c ce qu il y a de pire.
alors :
#define delete nop
et hop, tranquille

Moi, j'ai un autre problème existentiel
 
Y a parfois des programmeurs qui ont l'esprit vachement tordu. Là, j'apprend Perl et je lis en m tps les scripts qui ont été fait au boulot par d'autres programmeurs et y a des fois où c'est pas triste pour suivre leur raisonnement
 
Did'juuuuuuu !!!

normal... je suis en train de developper un petit soft pour une banque, et la personne qui sera en charge de la maintenance vient de passer dans le code (VB), et bien finalement elle a prevu de se reserver une journee pour ssayer de comprendre:
Ce qui peut etre logique pour un developpeur, ne l'est pas forcement pour un autre, d'autant plus qu'il faut avouer qu'a force de debuggage et autre modifs de versions, le code n'est pluis vraiment tout ce qu'il y a de plus homogene..

imhotep03 a écrit a écrit : bonne analyse + découpe en modules = bon programme

 
le truc, c'est de développer un soft en appliquant la démarche Génie Logiciel. C'est assez lourd comme mise en oeuvre, mais au moins, une fois le cahier des charges et le cahier des spécifs système et logicil signés, le client peut plus revenir dessus et faire rajouter des trucs, sauf accord mutuel. Cf. modèle du cycle en V.

ça rejoint ce qui a été dit:
Bonne analyse + bon découpage = bon programme + gains de temps la prochaine fois car on pourra peut-être réutiliser certains modules + facilite la maintenance.
 
à ce propos de maintenance, les commentaires, c'est vachement important!!! c'est chiant à foutre (on se dit, c mon prgm, donc je comprends ce que je fais) mais dans 6 moins, on se rappelle plus trop ce qu'on a fait au début...

Un truc important aussi, c'est, si le langage le permet bien sûr, I N D E N T E R
 
Crénom d'vindiou ! Au boulot, y en a un, si je le choppe
 
En 1 ligne, il me colle un if-then-else et il trouve le moyen de rajouter un commentaire par dessus !!!
 
Et y a une dizaine de lignes comme ça
 
Ah oui, c'est sur, ça fait du gain de ligne mais pour la compréhension, enfin pour moi, c'est pas toujours très top

Aricoh a écrit a écrit : Un truc important aussi, c'est, si le langage le permet bien sûr, I N D E N T E R   Crénom d'vindiou ! Au boulot, y en a un, si je le choppe   En 1 ligne, il me colle un if-then-else et il trouve le moyen de rajouter un commentaire par dessus !!!   Et y a une dizaine de lignes comme ça   Ah oui, c'est sur, ça fait du gain de ligne mais pour la compréhension, enfin pour moi, c'est pas toujours très top

A mon avis le terme "coder" viens de la...

le mieux c de tout ecrire sans espace, sans retour chariot non plus,(optimisation de l'espace lol) sans reflechir non plus,  (sinon c pas rigolo)..et euh surtout pas faire d'analyse...ca gache le plaisir ...ah oui aussi programmer l'ecran eteint (on est moins a meme de penser a autre chose)..ah ouais surtout ne pas mettre de commentaire.on s'en fout !ca sert a rien
ah ouais aussi mieux vaut tout faire en assembleur, en plus, c plus facile...tout ca fait evidemment sur un 386 avec un clavier QWERTY...
voila les regles d'or du programmeur !!

arglllllll

n'empeche que l'assembleur, ça poutre

Il n'y a pas que cela.
 
Quand un projet commence à être un peu gros, avec tout plein de petits modules ou classes, il y a d'autres dangers qui guettent. Par exemple, le nombre d'interdépendances enrte les classes/petits modules. Tu regardes une classe, comme ça, le code a l'air propre (bien indenté, avec des commentaires, noms de variables corrects). Mais quand tu commences à essayer de comprendre vraiment ce que fait le code, tu réalises que c'est un vrai plat de spaghettis : tout dépend de tout et utilise tout (et réciproquement ). Résultat : tu essaies d'extraire une classe et tout le projet vient avec.
 
Et ça, c'est une des plus grandes difficultés du métier, je pense, quand on rentre dans un projet existant. Et la pression de sortir vite un produit fait toujours foncer droit dedans... (je parle d'expérience )

under a écrit a écrit : le mieux c de tout ecrire sans espace, sans retour chariot non plus,(optimisation de l'espace lol) sans reflechir non plus,  (sinon c pas rigolo)..et euh surtout pas faire d'analyse...ca gache le plaisir ...ah oui aussi programmer l'ecran eteint (on est moins a meme de penser a autre chose)..ah ouais surtout ne pas mettre de commentaire.on s'en fout !ca sert a rien ah ouais aussi mieux vaut tout faire en assembleur, en plus, c plus facile...tout ca fait evidemment sur un 386 avec un clavier QWERTY... voila les regles d'or du programmeur !!

 
oui c'est clair under. Voici pour les optimiseurs fous une solution pour reduire le if then else au minimu (javascript) :
 
avant

 
apres

[edit]--Message édité par darkoli--[/edit]

Si vous voulez evitez les "Segmentation fault" sous linux ou les "la memoire ne peut etre read" sous win moi je vous le dis, en vérité, ecriver des drivers TRES bas niveau ... La sous linux si ca plante c le reboot immédiat personne saura que ca vient de vous

Ah la notation  bool?val1:val2 ... Elle est top !

under a écrit a écrit : le mieux c de tout ecrire sans espace, sans retour chariot non plus,(optimisation de l'espace lol) sans reflechir non plus,  (sinon c pas rigolo)..et euh surtout pas faire d'analyse...ca gache le plaisir ...ah oui aussi programmer l'ecran eteint (on est moins a meme de penser a autre chose)..ah ouais surtout ne pas mettre de commentaire.on s'en fout !ca sert a rien ah ouais aussi mieux vaut tout faire en assembleur, en plus, c plus facile...tout ca fait evidemment sur un 386 avec un clavier QWERTY... voila les regles d'or du programmeur !!

et puis utiliser des variables genre X,x,Xy,xY,xyz, ...
Ca c'est le top
et les commentaires, hein, c'est superflu...
Pour l'optimisation je suis d'accord, ce qu'on pense optimisé ne l'est pas forcémment et on peut perdre bcp plus en lisibilité (je pense à la dérécursification d'un backtracking par exemple )
Pour vraiment optimiser--> asm{....}  

ou lala vous est parti dans vos delires!!!!
 
j'voulais juste savoir si l'infomatique c'est toujours capilotracteur!!

Toujours, je parle d'expérience ...
 
D'autant plus quand tu bosses sur le développement d'un jeu pour les ... 8 - 12 ans ... et que tu entends les cris des Visiteurs 142687413 fois par jour (en moyenne )
 
Mais tu verras que souvent les phases de développement d'un projet, c'est: Facile   , hop je tape tout comme un barjo et je tire des missiles de code sur les murs puis je regarde mon code tiens ca marche pô je tourne en bourrique et je teste tout en m'arrachant les cheveux     finalement je trouve une erreur tuote conne genre une virgule oubliéeet ca m'épate je la corrige et là ca donne   trop cool et aussi un peu oh putain mais comment j'ai pu rester bloque la dessus, faut que je trouve une excuse technique debile pour mon boss sinon il m'exécute

>j'voulais juste savoir si l'infomatique c'est toujours capilotracteur!!  
 
pour que ça le soit encore plus pour les autres qui vont suivre que pour toi, tu écris du code le plus *obsfucated* que possible, avec les méthodes précédemment abordée (pas d'espaces, x==y?1:2, pas de commentaires, des variables qui veulent rien dire .... et en codant de la manière la plus tordue qui soit.
 
Tu verras, les suivants s'arracheront encore plus les cheveux que toi donc tu trouveras ton cas moins désespéré.    
 

MarvinLeRouge tu me rassure alors je suis pas le seul...
fin je sais pas si ça me rassure pour l'avenir........
Car on doit faire moins d'erreur par la site mais le peu qui reste doivent etre de plus en dur à trouver et voir à corriger......
Mais c'est vrai quand ça tourne c'est trop bon...
 
Quand au coup de pas commenter le code ,pas d'espace pas de retour chariot ,des variables qui veulent rien dire, c'est vrai c'est un coup à faire mais pour rire........
 
Parceque si tu dois faire une mise a jour la dessus dans 3 mois tu t'arrches le peu de cheveux qu'il te reste.....et il m'en reste pas beaucoup)

j'ai un conseil a te donner créer des objets bien spécifiques
comme ca si tu dois faire tel ou tel modif tu n'auras qua aller faire tes modif dans l'objets concerné au lieux de modifier tout ton code.
J'espere que je fut kler

Vous n'avez rien compris.
 
Le code illisible n'est pas du terrorisme informatique, on appelle ça la protection de l'emploi.

Heu... Je ne suis pas d'accord ! Moi aussi je suis du métier, et non seulement ça ne protège pas mon emploi (vu la vitesse à laquelle le code est jeté, ils sont capables de me jeter de la même façon), mais en plus, ça me file mal à la tête, d'essayer de comprendre du code mal écrit !!!!!!  

Un des probleme pour la lisibilité, c'est que quand on a un bug, on a tendance à faire ce qu'il faut pour le coriger sans trop s'inquieter de la coherence de l'ensemble. Le resultat est un programme qui fonctionne, mais un code qui fait un peu patchwork.  
  C'est pourquoi, dans le periode un peu creuse (ca, c'est un peu la loterie. Y'a des boite ou t'en aura jamais, y'a des boites ou t'aura plus de periode creuse que de periode de travail), je réécrit entierement mes programme. Je ne les debugue pas, je ne les ameliore pas, je les re-écris simplement.

Pour bien programmer, perso je pense que la fasse de conception est la plus importante, Une fois le cahier des charges bien établie, il faut couper le projet en fonctions qui doivent etre le plus générique possible et indépendantes. Apres ben pour la maintenance les commentaires et les indantations c'est tres tres bien. De plus mieux vaut commencer par ecrire les commentaires comme ca cela t'oblige a reflechir sur ta fonction.

templates
interfaces
Propriétaires/Utilisateurs
STL
Doxygen
indentation
=code propre

 "ce qui se conçoit bien s'énonce clairement"
donc un code surlequel on a bien réfléchi doit s'écrire facilement, si tu bloques, reprend la phase de conception

BiFace > Je plaisantais évidemment
 
Il ne faut pas oubiler que l'on ne raisonne pas, en entreprise, en termes de beauté des fintes employées, mais en argent.
 
Et donc, on pourra accepter qu'un truc soit assez lent, ou qu'on dépasse un peu les délais, si on sait que derrière la maintenance est facile.
 
J'ai eu une maintenance à faire sur du VB il y a quelques mois : truc codé comme un porc, j'ai mis 10 jours à faire un truc qui devrait être quasi-immédiat.
 
Résultat, j'ai gagné le droit de recoder entièrement l'appli