Discussion :

[koala01]

Je vais quand même modérer quelques peu mes propos

Je comprends parfaitement qu'il n'y a que 24 heures dans une journée, que l'on n'aime pas trop coder dans la voiture, qu'on souhaite dormir, manger et, tant qu'à faire, passer un peu de temps en famille.

J'ai donc bien conscience du fait que, l'un dans l'autre, une journée de huit heures de boulot, c'est déjà bien assez si l'on peut se permettre (pour une raison de délais, non de budget) de s'y tenir.

Et je comprends donc parfaitement aussi que, lorsqu'on a des délais très (trop ) courts, il faut parfois, même si c'est malheureux, faire des choix.

Si, l'on se trouve dans cette situation, je comprends --bien que je le regretterai toujours -- que l'on puisse "zapper" l'écriture d'un cartouche ou la mise au point de tests unitaires.

Ce n'est, je peux te l'assurer, pas sur ces deux points particuliers que portait mon jugement.

Par contre, là où je ne peux m'empêcher de penser qu'il y a un très sérieux manque qui n'est imputable ni aux délais ni au manque de moyens financiers, mais bel et bien d'une manière générale à l'équipe de dev elle-même (par je-m’en-foutisme ou par manque de compétence ? ca reste la vraie question ) c'est quand on commence à parler de copier / coller, surtout quand on parle de code issu de l'équipe de dev elle-même.

Comprends moi : je n'ai pas "grand chose" contre le fait que l'on puisse se dire "tiens, telle partie de l'application est exactement identique à ce que j'ai fait pour un autre projet, je vais copier les N fichiers à la volée pour la récupérer". S'il n'était pas prévu que le projet d'origine finisse sous la forme d'une bibliothèque maison, cela peut parfaitement se comprendre.

Je trouverais sans doute dommage que l'on ne prenne pas le temps de transformer cette partie intéressante en "bibliothèque maison", mais bon, il faut un minimum de créneaux horaire pour pouvoir le faire

Qu'à la limite, tu décides même de copier / coller un code que tu trouves sur internet et qui correspond à ton besoin (au prix d'une adaptation minimale s'entend ) ne m'ennuie encore pas énormément si tant est que tu puisses avoir la garantie de stabilité dont tu as besoin.

Par contre, là où je ne suis plus d'accord du tout, c'est quand on se retrouve avec 2, 5 ou 10 fois un code exactement identique qui a été copié/collé uniquement parce que le type a eu la flemme de le factoriser en une fonction qu'il pourrait appeler... A moins qu'il ne se soit pas rendu compte qu'il pouvait le faire, ce qui est encore pis .

Dans ce cas, ce n'est ni une question de budget, ni une question de temps, mais c'est bel et bien un problème de compétence et/ou de motivation du personnel de l'équipe et dans ce cas là, il y a vraiment des questions à se poser, tu ne crois pas

[CodeurPlusPlus]

Toute la question est de savoir si l'on maîtrise les bases de l'algorithmique et de la programmation, et si on les as réellement pratiquées pendant ses études / stages.

Celui qui maîtrise va avant tout utiliser sa logique, efficacement secondée par sa mémoire (et les bases doivent être dans le disque dur du cerveau, par dans sa ram, hein !)

Celui qui maîtrise, lorsqu'il prend l'habitude d'utiliser telle ou telle bibliothèque ou framework (et pas cinquante bibliothèques différentes + trois frameworks pour écraser une mouche), parvient à garder un nombre raisonnable de choses en mémoire pour pouvoir travailler efficacement sans utiliser de moteur de recherche toutes les cinq minutes.

De temps en temps, relire de la doc est indispensable, en lire d'avantage pour les besoins futurs aussi. Mais dans tous les cas celui qui maîtrise passe bien le plus gros de son temps de codage à coder et non à chercher un programme déjà écrit qui fait le boulot pour lui.

C'est pour dire : même lorsque je m'attaque à une bibliothèque que je ne connais pas du tout, je n'ai pas besoin de faire de copier-coller d'un code d'exemple pour le modifier ensuite. Je lis tout ce que je peux de doc, et puis ensuite je code à partir d'une page blanche. Cela donne une souplesse nécessaire pour écrire du code avec une vraie valeur ajoutée.

Celui qui ne maîtrise pas ses bases, celui qui a toujours été un boulet, celui-là continuera à faire ce qu'il a tout le temps fait. Pendant ses études, au lieu de faire le TP que ses profs lui demandaient de faire, il en cherchait un tout fait, modifiait un peu le code, et croisait les doigts pour ne pas se faire attraper. Celui-là, après x années, il ne sait toujours pas architecturer un module ou bien évaluer la complexité d'un algorithme, encore moins en inventer un en cas de besoin, mais il s'en fout : il suffit de faire des copiers-collers un peu intelligents pour avoir un salaire versé par une entreprise de seconde zone.

[el_slapper]

Pour répondre à Koala, rendre un composant réutilisable répond à la règle de trois : trois fois plus cher à créér, et doit être testé dans trois contextes différents avant d'être validé.

C'est souvent rentable quand même... mais la pression de la hiérarchie pour un truc qui marche avant-hier, sans faute, fait qu'on ne peut pas toujours se permettre l'investissement. Il est arrivé que je le fasse quand même, mais on m'a bien fait comprendre que je n'avais pas interêt, mais alors pas du tout, à me louper.

Dans ces conditions, si je ne suis pas sur de mon coup(et il faut souvent se décider en quelques secondes), je m'abstiens. Hélas.

[Matthieu Vergne]

• Que cela ne prend pas plus de temps de se poser cinq minutes pour se poser les bonnes question que de passer son temps à déboguer du code mal écrit,
• Que l'on passe globalement beaucoup moins de temps à déboguer son code lorsque l'on a pris la peine de se poser cinq minutes
• Qu'il y a des gens qui sont beaucoup plus capable de respecter les délais que d'autres en fournissant un code de meilleure qualité (comprend : contenant moins d'erreur)
• Que, comme par hasard, c'est souvent ceux qui n'arrivent pas à rendre un travail correspondant au point ci-dessus qui se plaignent le plus souvent de "n'avoir pas le temps"

Pour ma part, je résumerai à : il y a ceux qui savent où consommer leur temps, et ceux qui ne savent pas où le perdre.

[moldavi]

Bonjour

Par contre, là où je ne suis plus d'accord du tout, c'est quand on se retrouve avec 2, 5 ou 10 fois un code exactement identique qui a été copié/collé uniquement parce que le type a eu la flemme de le factoriser en une fonction qu'il pourrait appeler... A moins qu'il ne se soit pas rendu compte qu'il pouvait le faire, ce qui est encore pis .

Je suis d'accord avec cela, et je comprends mieux vos réticences à l'égard du copier/coller.

Je pense que la plupart des personnes ici parlent de copier/coller "utile" et non pas de copier/coller "idiot à répétition".

[koala01]

Je pense que la plupart des personnes ici parlent de copier/coller "utile" et non pas de copier/coller "idiot à répétition".

Si seulement c'était vrai...

Je ne vise personne en particulier, et surement pas toi, mais, de l'expérience que j'ai de code de production et du forum, je peux t'assurer que c'est malheureusement pas forcément le cas

[Invité]

Par contre, là où je ne suis plus d'accord du tout, c'est quand on se retrouve avec 2, 5 ou 10 fois un code exactement identique qui a été copié/collé uniquement parce que le type a eu la flemme de le factoriser en une fonction qu'il pourrait appeler... A

J'ai déjà fait malheureusement partie de ceux là
Je pense que ya dysfonctionnement, mais j'expose quand même les faits parce que c'est intéressant, un peu..

Supposons qu'on cerne de la dupp de code à plusieurs endroits.
Première question:
est-ce que je factorise? moi? alors que c'est pas mon code.

Bon, ok, on y va.

2) Comment je factorise, où, je vais créer une indirection supplémentaire si les deux codes sont dans deux libs différentes, est-ce pertinent d'en créer une autre (au risque qu'elle finisse par s'appeler tools ou utils )

Bon allez créons une lib ou updatons le code...


3) Bon il va falloir s'assurer que le code modifié marche. Redélivrer les différentes libs impactées. Pour peu qu'il y a des procédures un peu lourdes, valgrind, deux trois non bincompatibilités en fonction du refactoring, etc... ca prend du temps.
--------
De l'autre côté:
hop je copie les lignes je modifie les noms, je check les inputs output. C'est réglé.

Bon après c'est sûr que quand il faut faire un changement sur des lignes duppliquées c'est la misère, mais avec deux trois seds, on s'en sort...


====================
Je dis pas que copier coller c'est bien. Mais je comprends bien quand certains avec une charge assez conséquente, préfèrent se concentrer sur du code fonctionnel, glisser des copier-coller, quit à refactoriser plus tard quand c'est plus calme.

Le deuxième point, c'est :
Supposons qu'on a une énorme archi. L'idée c'est donc de prendre plein de personnes, et de faire des modules. Ainsi un groupe peut se concentrer sur une partie du projet, et il suffit de définir des interfaces entre ces groupes.
Maintenant il apparait un point très simple: il est possible qu'il y ait redondance de fonctionnalités/code partagée par ces groupes.
Tu n'as pas le budget, et tu n'as pas non plus le pouvoir pour rajouter un troisième groupe qui "factorise".
=>tu duppliques donc le code de l'autre groupe (ou tu recrèes)

Ce point est un peu plus triste puisque quelquepart, on ne peut pas y faire grand chose
(demander à l'autre groupe de fournir une librairie pose évidemment le problème de la maintenance, des ajouts etc, et on a pas envie de perdre du temps pour celui qui utilise gratuitement notre lib)

PS: ce poste concerne tous types de copier coller, les utiles, les idiots aussi

[Matthieu Vergne]

Avoir un code propre c'est toujours un effort à fournir. Soit on le fournit soit on ne le fournit pas. Même si tu nous sors des exemples de situations où il semble qu'on ne puisse pas le faire, ça ne change rien :

- dans le premier cas, tu parles d'un code que tu retrouves à plein d'endroits que tu ne connais pas -> tu n'as aucune raison de le factoriser parce que tu ne sais pas si ce code est là pour les même raisons (tu ne connais pas le rôle du code). On ne factorise pas du code parce que c'est le même, mais parce qu'il a le même objectif. Le fait qu'il soit le même est seulement un (gros) indice d'un objectif similaire. Une factorisation ça se fait intelligemment.

- dans le second cas tu dis "on n'a pas les ressources pour ça". Dans l'absolu ce n'est jamais vrai (sinon prouvez-moi le contraire). C'est seulement une autre façon de dire "on a décidé qu'il n'était pas prioritaire de mettre des ressources là dessus" (en évitant de donner l'idée de répondre "qui ça 'on' ?", mais c'est un autre problème {^_^}). Autrement dit, le fait que personne ne le fasse, ce n'est pas par manque de choix, c'est un choix à part entière, nuance. Même si on ne sait pas toujours qui a fait ce choix.

Un code propre est un objectif en soi. On l'a ou on ne l'a pas. Mais si on l'a, comme tout objectif, il faut se donner les moyens de le satisfaire. Si tu donnes des cas où on n'a pas cet objectif, alors ça n'a pas de sens d'en parler.

[Uranne-jimmy]

Je suis pas le plus pro des informaticiens, et parfois il semble que certaines parties de codes sont factorisable. Au début pour ce genre de cas j'ai tenté et je me suis retrouvé dans un situation plus clair mais plus couteuse en temps et en code. Je m'explique : le cas d'un opération similaire en tout point mais dont les attributs changent suffisamment pour qu'il soit nécessaire de faire une fonction avec énormément d'attributs pour factoriser. Au final on se retrouve avec des fonctions bien nommé qui structures mais c'est un casse tête monstrueux pour les utiliser.

Dans ce cas, est-ce réellement mal de copier ?

[Matthieu Vergne]

Si tu parles du cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
fonction1(Type1 var1, Type2 var2) {
  ... code X ...
}

fonction2(Type3 var1, Type4 var2) {
  ... code X ...
}

que tu factorises en quelque chose du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
fonction1(Type1 var1, Type2 var2) {
  fonction3(var1, var2, null, null);
}

fonction2(Type3 var1, Type4 var2) {
  fonction3(null, null, var1, var2);
}

fonction3(Type1 var1, Type2 var2, Type3 var3, Type4 var4) {
  ... code X ...
}

Alors la factorisation n'est pas intelligente. Dans ce cas tu es censé généraliser tes types, par exemple voir que Type1 et Type4 correspondent à deux cas particuliers d'un même concept (disons TypeA) et Type2 et Type3 à un autre (disons TypeB) puis factoriser en conséquence :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
fonction1(Type1 var1, Type2 var2) {
  fonction3(var1, var2);
}

fonction2(Type3 var1, Type4 var2) {
  fonction3(var2, var1);
}

fonction3(TypeA var1, TypeB var2) {
  ... code X ...
}

Je ne prends pas en compte les options que tu trouves dans un et pas dans l'autre (qui feraient donc vraiment des arguments différents) car ça ne suit pas l'hypothèse d'une "opération similaire en tout point". Cela dit même si tu as des cas avec ça, ça implique d'avoir effectivement tous les arguments. Sinon il faut revoir ton algo pour le simplifier (typiquement en généralisant aussi).

[Mat.M]

Si tu parles du cas :
...

avec l'exemple donné on peut peut-être utiliser des types/fonctions génériques ( en C++ ça s'appelle des Templates)..à voir si c'est pertinent.
Les langages orientés objets comme C#,VB NET et C++ les supportent.
Sinon ce que tu décris avec des morceaux de code ça ressemble à une sorte de "surcharge" de méthode d'objet

[Mat.M]

Je suis pas le plus pro des informaticiens, et parfois il semble que certaines parties de codes sont factorisable. Au début pour ce genre de cas j'ai tenté et je me suis retrouvé dans un situation plus clair mais plus couteuse en temps et en code. Je m'explique : le cas d'un opération similaire en tout point mais dont les attributs changent suffisamment pour qu'il soit nécessaire de faire une fonction avec énormément d'attributs pour factoriser. Au final on se retrouve avec des fonctions bien nommé qui structures mais c'est un casse tête monstrueux pour les utiliser.

Dans ce cas, est-ce réellement mal de copier ?

re : en créant une classe on peut avoir une méthode de classe ayant plusieurs définitions/implémentations ce qui revient au final à une sorte de copier-coller

[Uranne-jimmy]

En concret j'ai là un exemple parfait : Une procédure complète qui existe et qui a le même but (créer un fichier Excel spécifique dans ce cas) mais selon l'ampleur des données qu'on a en entrée, des subtilités changent, le soucis c'est que le code fait bien 500 lignes et l'ensemble des subtilités représente énormement d'arguments à modifier.
J'ai donc préféré le copier coller à la factorisation qui m'aurait posé un truc dans ce genre :

fonction(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13, arg14, arg15, arg16, arg17, arg18, arg19, arg20 ....)

[Matthieu Vergne]

Et là tu crées ce qu'on appel une structure de données. La complexité est la même, mais typiquement tous ces arguments forment une logique commune. Du coup, tu fais une structure de données qui les rassemblent tous (ou tout du moins ceux qui dépendent vraiment d'une logique commune) et tu te fais éventuellement une factory (design pattern) qui te permettent de générer des structures pré-remplies (valeurs par défaut). Ensuite, pour chaque cas particulier, tu n'as qu'à utiliser la version pré-remplies qui correspond le mieux à ton contexte et changer le peu que tu nécessites de personnaliser. Tu peux aussi voir pour un builder (un autre design pattern) qui te permet de construire progressivement cette structure (ça formalise mieux la logique si celle-ci est complexe). Et au final ta fonction prend seulement cette structure de données comme argument.

[Uranne-jimmy]

Vous prouvez donc qu'il y a toujours moyen de factoriser pour qui est assez habile et organisé pour le faire, je n'ai donc plus aucun argument pour limiter l'usage de la factorisation ^^'
Merci bien.

[Matthieu Vergne]

Je prouve rien, je soumet des solutions classiques à des problèmes classiques {'^_^}.

Si tu veux une preuve, la factorisation n'est en soit que le remplacement d'un bout de code par une fonction qui mène à ce bout de code ou à un bout de code logiquement équivalent (qui donne au moins les même sorties pour les même entrées, mais on peut être plus stricte). Ce n'est donc qu'une question de représentation, on ne change rien à la logique du code à proprement parler. Si tu commences à changer des bouts de logique, là c'est un autre problème (qui ne rentre pas dans le cadre de la factorisation proprement dite). De ce fait la factorisation est toujours possible tant que le langage permet un tel changement de représentation. Ce qui est discutable en revanche, c'est à quel point une factorisation données est pertinente, et là par contre il y a de quoi débattre.

[simonf]

Ma mémoire est très mauvaise et je n'ai pas spécialement confiance en elle. Je le sais. Je vérifie systématiquement certaines choses. De plus, je crois que notre travaille consiste de plus en plus en l'implémentation de librairies existantes, multiples et juxtaposées et que, humainement, nous ne pouvons pas retenir une telle masse d'informations (hormis certains qui ont une mémoire exceptionnelle).

Je dirais que c'est presque une mauvaise pratique de vouloir tout faire par soi-même et que cela décourage la ré-utilisation de code (de bonne qualité). Depuis les deux dernières années, mon expérience avec le fameux CPAN de Perl n'a fait que confirmer celà de plus en plus : pour (presque) tout ce que vous avez besoin de faire il existe certainement déjà des personnes qui se sont posé le problème et l'ont compilé dans un module. Pourquoi, par fierté, vouloir refaire celà entièrement ?

Pour moi, cette question va de la structure de contrôle basique d'un langage à une librairie entière : si mon EDI permet la complétion de code automatique d'une simple boucle for, je ne vais pas me fatiguer à désactiver cette fonctionnalité. Pareil, si une librairie ou un module ont été écrits, je ne vais pas m'amuser à le refaire juste parce que c'est rigolo. Mieux vaut à ce moment participer à améliorer la doc, signaler un bug, écrire un article de blog sur la librairie en question.

La question des "mauvais codes existants" est très intéressante aussi... Il est facile de considérer que telle ou telle librairie ou morceaux de codes sont "mauvais". Il existe aussi des processus de validation sociale qui font que la qualité du code peut être évaluée facilement, soit parce qu'il s'agit de logiciels libres qui ont été relus par de nombreuses personnes et que vous utilisez une version stable, soit parce que, comme sur Stack Overflow, avant de copier-coller une portion de jQuery qui semble convenir à votre besoin, vous pouvez vous appuyer sur la "réputation" de la personne qui a fourni la réponse...

[epsilonenadia]

Débutante alors du copier coller, mais sans ma mémoire même le copier coller ne marche pas forcément
Merci pour se forum

[Julien698]

Perso j'utilise des bouquins et l'auto complétion, après s'il y a des fonctions que je ne connais pas du tout, oui ça peut m'amener vers MSDN ou google.

[SaraMida]

Bonsoir,
je voulais répondre à cette question pour vous dire sincèrement que je ne trouve pas l'utilité d'apprendre des syntaxes qui ne servent à rien. Se rappeler du principe oui mais la syntaxe non :d à titre d'exemple : La fonction switch case qui est présente dans tout les langages. Se rappeler de son fonctionnement oui mais sa syntaxe différa d'un langage à autre et pas la peine d'apprendre une dizaine :p (c#,Java,C++....)
Merci