Discussion :

[stuntyman]

Bonjour à tous,
Dans le cadre d'une expertise dans une procédure civile,
je suis amené à analyser le code source Windev d'un progiciel.
J'ai calculé le nombre de ligne de code par jour produit dans ce progiciel.
Ma problématique est la suivante : quelle est la moyenne du nombre de ligne de code par jour pour un développeur Windev plutôt expérimenté.
Cette moyenne me permettra de comparer avec mes résultats afin de déterminer si l'auteur à réellement écrit toutes ces lignes de codes ou s'il était partisan du copier-coller.
Merci d'avance pour vos réponses.

[Hemgé]

???????????????????

Dans votre approche,

• la difficulté du développement à entreprendre intervient-elle ?
• la connaissance préalable de la problématique est-elle prise en considération ?
• que signifie la notion de "plutôt expérimenté" ?
• le développeur est-il censé réfléchir ?
• quelle est exactement l'ampleur et la difficulté du développement : interconnexion à d'autres application ou bases de données, interrogations et mise à jour automatiques à partir de serveurs tiers etc, interfaçage avec du matériel ?
• doit-il préférer démarrer à partir d'une page blanche ou peut-il se livrer à une recherche ciblée et judicieuse de solutions existantes et disponibles ?
• à résultat final équivalent, la qualité et la fonctionnalité sont-ils péjorés par la démarche : '(ré)invention' de la roue versus collationnement et intégration de briques de code ?
• faut-il préférer un développement plus rapide et apparemment 'efficace' au détriment de la qualité, de la maintenabilité et d'autres qualités du développement

Etc.

Bref, je ne vois pas très bien comment vous allez ficeler tout cela.
Votre approche m'apparaît un peu 'abrupte', peu nuancée, voire fruste.
D'autres auront peut-être un autre avis.


Par ailleurs, est-il raisonnable sur le plan déontologique d'accepter une expertise portant sur un environnement de développement que vous ne connaissez apparemment pas (ou très peu) ?

Hemgé

[philippe30]

Un bon développeur codera avec un code plus lisible , mieux optimisé , plus rapide à la différence d'un autre développeur qui sera tout le contraire
Allez vous compter les lignes de commentaires sur le fonctionnement du logiciel ?

Cette démarche est très étonnante

Cette expertise civile est motivé par quoi ?

Tarif du logiciel , bugs , pourquoi se référé au nombre de lignes ?


Philippe

[fffttt]

quelle démarche ! J'aimerais bien connaitre la finalité!

Vous pensez qu'il y en a trop ou pas assez?

Le code peut très bien venir de classe / collection de procédure "générique" écrite auparavant. Est ce grave d'avoir fait un copier/coller? Je pense pas.

[stuntyman]

En effet quelques précisions ne ferait pas de mal.
Dans mon propos initial je ne me suis pas attarder sur le contexte, allant directement à l'essentiel.

Le progiciel est de type "gestion d'un commerce" et il a été développé en 8 mois.
Le développeur connaissait déjà la problématique, pour avoir antérieurement développer un progiciel similaire.
Son code source n'est pas optimisé et est peu commenté.
Mon approche parait peut être abrupte car j'ai déjà terminé l'analyse du code source du progiciel développer en windev 16, environnement de développement que je connais.

Pour terminer mon analyse qui a commencé il y a un an, le dossier n'étant pas simple du tout, je dois déterminer une limite maximale cohérente de nombre de ligne de code par jour.
Mon comptage de ligne de code par jour prend en compte les commentaires mais pas les lignes vides.
Une fois cette limite déterminer je pourrais la comparer à mes résultats et ainsi pouvoir dire si du code source pourrait provenir de copier/coller.
J'ai bien sûr auparavant identifié les procédures/collections génériques afin de les écarter de mes résultats afin de me concentrer que sur le code source spécifique et représentatif du savoir-faire du développeur.

Cette expertise concerne une concurrence déloyale.
La finalité de cette démarche est d'établir un ratio de "nombre de ligne de code / jour" et de vérifier si ce ratio est cohérent par rapport aux pratiques du métier.

Voilà, en espérant que ces précisions apportent réponses à vos questions.

[serendib]

Hemgé à tout dit en termes galants.

Mais comme je ne suis ni galant (avec les mecs) ni politiquement correcte,
je dirais pour ma part que c'est du grand n'importe quoi.
Il y avait déjà les contrôleurs fiscaux (ça peut se justifier),
maintenant il y a les contrôleurs de lignes de code.
Il serait peut-être intérressant pour vous de contrôler aussi sa vitesse de frappe au clavier.
Bref, à passer au zapping.

En effet quelques précisions ne ferait pas de mal.
Mon comptage de ligne de code par jour prend en compte les commentaires mais pas les lignes vides.
Hugo

Ça c'est la meilleure !

[tatayo]

Bonjour,
Si j'importe le Webservice de Magento "à l'ancienne", WinDev me génère plus de 250 procédures, avec quelques dizaines à plusieurs centaines de ligne de codes.
Le tout en moins de 2 minutes...

Je me trouve dans quelle case ?

Tatayo.

[frenchsting]

Mon épouse travaillant dans le juridique, je comprends la démarche pour rechercher si le développeur a bien fait son boulot : grosso modo savoir s'il a réellement bossé (parti de presque rien et a tout monté) ou s'il s'est simplement contenté de modifier les logos déjà présents dans une appli antérieure.

Comme l'ont déjà souligné mes camarades, et pour faire court, ce n'est pas évident à démontrer : copier-coller de bouts de codes trouvés de-ci de-là, génération automatique de code (cf Tatayo)...

Pourrais-tu préciser dans quel cadre de concurrence déloyale ? Je ne vois pas le rapport avec le temps de développement...

[philippe30]

La concurrence déloyale avec analyse du code source ....en comptant le nombre de lignes de code.

Arrêtons ce délire , si demain je sors une copie de Windows à moitié prix je veux bien être mis en accusation par contre des logiciels de commerce il y en a des centaines.

Croyez vous que les codes sources des autres soit disponibles ? Non alors que cherchez vous ?

Vous voulez connaitre la rentabilité du développeur en terme temps de nombre de lignes / nombre de jours ? aucun sens pour n'importe quel développeur.
Des exemples de générations automatiques ont été évoqués , le temps ou l'on "pissait" de la ligne et que l'on était payé à la ligne produite fait partie d'un autre temps ....

Un logiciel se paye pour le service rendu , un contrat est fait en amont avec un cahier des charges pour définir les fonctionnalités du logiciel.
Si les fonctionnalités définies initialement ne sont pas implémentées alors oui il y a un problème entre le contrat et le résultat.

Votre démarche est du vent et n'a aucun sens

Philippe

[Hemgé]

Mon comptage de ligne de code par jour prend en compte les commentaires mais pas les lignes vides.
.... pouvoir dire si du code source pourrait provenir de copier/coller.
J'ai bien sûr auparavant identifié les procédures/collections génériques afin de les écarter de mes résultats afin de me concentrer que sur le code source spécifique et représentatif du savoir-faire du développeur.

Les lignes vides peuvent pourtant avoir été honteusement copiée du logiciel possiblement cannibalisé.
Elles concordent parfaitement aux lignes originales, même si elles pourraient avoir été subtilement déplacées ou regroupées.

Du code similaire peut avoir été copié/collé ou re-dactylographié. C'est la même chose ou c'est différent, parce qu'il y a quand plus d'heures prestées si on re-dactylographie tout ?

Une procédure générique, c'est quoi, en terme de concurrence déloyale ? Parce qu'une procédure générique, c'est a priori le truc non brevetable sur lequel il n'y a pas de droits intellectuels.

Vous cherchez à identifier le code représentatif du savoir-faire du développeur ?
N'a-t-il aucun savoir faire à repérer du code disponible, libre de droit et à l'agréger avec une plus-value ?
Ne faudrait-il pas chercher à identifier le code représentatif de l'application présumée piratée ?

Vous avez un problème de crédibilité et de présentation de votre démarche, dont les modalités ne m'apparaissent par ailleurs pas solides sur les plans conceptuel et fonctionnel.
A vous lire, s'il s'agit de concurrence déloyale, on imagine qu'elle relève d'un piratage de sources et non d'un détournement de clientèle.
Dans ce cas, il conviendrait peut-être de vous focaliser sur la mise en évidence de portions de code strictement identiques avec l'application originale prétendument piratée et en proportions non négligeables.
Pour le reste, les concepts sont difficilement brevetables et s'ils ne l'ont pas été dans un délai raisonnable, ils sont probablement libres de droit, même pour un employé plus ou moins indélicat, ceci sous réserve des termes de l'éventuel contrat que nous ne connaissons pas.

Quant à rechercher des concepts originaux dans un logiciel de type "gestion de commerce", cela ne doit pas être évident avec la multitude de progiciels existant ou ayant existé et le nombre de morceaux de code plus ou moins aboutis qui traînent un peu partout.

Et, à moins qu'il ne s'agisse d'une croisade qui a pris un tour passionnel, est-ce que la somme d'heures que semble représenter votre intervention à ce jour, se justifie par rapport au préjudice présumé ?

[DelphiManiac]

Pour pouvoir répondre, il me faudrait plus d'informations :

Le clavier utilisé était-il un clavier mécanique ?
Quel age a le développeur ? (parce qu'en vieillissant on fait un peu d’arthrite)
Son PC était très rapide ? si oui cela permet de gagner du temps au démarrage le matin.
Fume-t-il ? si oui il faut soustraire les pauses cigarettes.
Quelle pertinence apporterez-vous à ma réponse, que je puisse pondérer au mieux celle ci ?

N'hésitez pas à ajouter tout éléments pertinents qui pourrais m'aider à mieux quantifier le nombre de lignes au caractères prêt.

DelphiManiac, expert en comptage de lignes.

[R&B]

Bonjour

Je retiens la problématique posée clairement et ni la méthode ni l'intention :

Quelle est la moyenne du nombre de lignes de code par jour pour un développeur Windev plutôt expérimenté.

Je répondrais facilement : moins qu'un développeur peu expérimenté.
En effet, cette expérience va lui servir pour optimiser précisément ses développements par des procédés permettant de produire moins de code :
Meilleure gestion des types, des portées, nommages et indirections qui permettent de factoriser des traitements qu'un néophyte aurait simplement dupliqué/adapté (étant plus rapide mais impliquant de facto une rupture dans sa capacité de maintenance, sans parler le la perte croissante de qualité).

En conséquence la production en volume n'est pas un argument recevable amha.

Travaillant en environnement partagé, il m'est difficile de donner cette mesure dans le temps. Le ratio de la propriété du code dans un projet à plusieurs est faux car on ne présente que le dernier ayant modifié une ligne. Il nous faudrait une mesure quotidienne des variations avec la veille mais aussi des modifications et suppressions...

En outre, proposer une solution logicielle et à fortiori en WinDev (L4G, RAD...), ne se résume plus qu'en un nombre de lignes. En effet, vous ométez (à dessein ?) le modèle de données, l'IHM (pas les champs mais l'ergonomie, l'expérience utilisateur etc..).

Pour votre évaluation, voyez plutôt du coté de la structuration de ses créations, de l'uniformité des résolutions de problématique, de la factorisation.
Il vous est possible de l'isoler avec une feuille et un crayon et de poser un problème pour analyser sa manière de le résoudre.

Comme pour les chasseur, il y a les bon les et mauvais. Les mauvais fabriquent des programmes, et les bon fabriquent des programmes...

Enfin, pour le "copier-coller", ce terme englobe deux notions distinctes.
- La première qui vient à l'esprit : copier les autres.
C'est effectivement une dérive qui s'accroit dans la profession (internet, projets open-source...). Le pire est alors le comportement qui tends à s'approprier une solution copiée : "Au royaume des aveugles, les borgnes sont rois".
Il n'y a pas de honte de peindre une boite pour la rendre visible, mais de là à clamer l'avoir inventée et fabriquée il y a un pas que certain franchissent sans soucis.
- La seconde : c'est la duplication modifiée de code que je cite à propos de ceux que je qualifie poliment de néophytes dans mon message. Là, pas besoin d'être un "expert" informatique pour le démasquer.

Je rebondis enfin sur votre statut d'expert en mesure avec la question. L'expert n'est-il pas précisément celui qui a ces connaissances ?

[fffttt]

ce qui est flippant je trouve au passage.
c'est le crédit apporté à ces experts.

Le mec il a peut etre pompé le soft de son ancien employeur sur lequel il a travaillé puis l'a revendu une fois parti.
déjà est ce ça? c'est ce que vous essayé de montrer?

[michel.souris]

Le nombre exacte de ligne de code par développeur plutôt expérimenté est de (pour une journée moyenne de 7.25 heures) :

-> 86.73 lignes intelligentes
-> 261.49 lignes stupides
-> 84.12 lignes de commentaires

En outre un développeur plutôt-expérimenté peut au maximum factoriser 5.89 traitements par jour (au delà il y a un risque de détérioration du développeur plutôt-expérimenté).

A noter qu'un développeur plutôt-très-expérimenté possède des performances 2.37 fois supérieures. On conseille généralement d'utiliser ce type de développeur car le ratio de coût/nb de ligne de code est de 5.45 contre 3.89 pour les plutôt-expérimentés.

Si vous avez d'autres questions plutôt-à-la-con je me ferais un plaisir d'y répondre.

[Nicolas_Jeanneau]

Bon sang, tu viens de me plomber ma journée : moi qui code en moyenne 418.94 lignes par jour, je m'aperçois que je suis en dessous de la moyenne (tiens, d'ailleurs, c'est forcément ce qui doit expliquer pourquoi ma demande d'augmentation de 20 % n'est pas passée cette année ...). Bon je m'en vais te coder une tournée de boucles qui ne servent à rien histoire de combler mes lignes manquantes

à +

[michel.souris]

Il ne faut pas être inquiet. Tout dépend de la plutôt-catégorie dans laquelle tu te trouves...

Enfin pour paraphraser Coluche : de toute façon de l'intelligence on a toujours assez vu que c'est avec ça qu'on juge. Ben pour les lignes de codes intelligentes c'est pareil...

[stuntyman]

ce qui est flippant je trouve au passage.
c'est le crédit apporté à ces experts.

Le mec il a peut etre pompé le soft de son ancien employeur sur lequel il a travaillé puis l'a revendu une fois parti.
déjà est ce ça? c'est ce que vous essayé de montrer?

C'est exactement ça.
Je dispose des codes sources du logiciel original à comparer avec celui qui a été "pompé".

Je vous remercie pour toutes vos réponses.

[Ry_Yo]

Bonjour,

votre post à le mérite d'avoir posé un petit débat au sein de notre service info....
En étant moins agressif et comprenant la démarche judiciaire, je rejoins mes confrères en disant que se baser sur un nombre de ligne écrite à la journée n'est pas une preuve irréfutable.

Mais la réflexion mérite quand même d'être poussée... car la question au final est : A qui revient la paternité du code ?

Mon épouse travaillant dans le milieu de la recherche doit impérativement garder et dater tout document écrit ou même griffonner sur un brouillon... Car s'il y a un souci juridique sur un brevet, toutes pièces apportées au dossier prouvant l'antériorité des idées ou autres peuvent faire la différence....

Personnellement, pour avoir fait des audits techniques et si je devais prouver ceci, et encore, je ne sais pas si ces arguments seraient "recevable", je me concentrerais sur 3 points :

- la date d'écriture du code. Généralement, moi le premier, je recycle énormément de code, donc un projet de 2015 peuvent avoir des lignes de code avec un marqueur temps de 2010. Pourquoi ? parce que j'ai importé une collection de procédure ou autre fait à cette époque... A moins que le développeur soit parano ou s'attendait à cela, il n'a peut-être pas ré-indenter TOUT son code, donc le timecode est toujours celui d'origine. Or si il est dans une boite depuis 2015, il ne peut pas avoir produit du code de 2010...

- ensuite j'essaierai de prouver un % de similitude. un copier/coller va donc laisser le même nom de variable, la même aération de code, etc...

- enfin nous sommes en constante amélioration. Un code produit en 2010 sera différent de 2015. Partant de ce postulat, je rechercherais un "bug" dans le code de 2010. Et si je le retrouve en 2015 exactement au même endroit, alors un soupçon peut émaner...


Voici les quelques pistes qui me semblent plus pragmatique, mais je peux me tromper...

Cordialement.

[stuntyman]

Merci pour votre réponse.
Le dossier étant toujours en cours, je ne peux vous donner trop d'informations.
C'est dossier d'une part de "concurrence déloyal" mais surtout d'autre part de "copie de code source".
J'ai d’ailleurs déjà identifier quelques jolies "copier-coller" de codes.
Mon analyse ne se base pas uniquement sur ce "ratio de ligne de code par jour", cette problématique ne concerne que 5% du dossier.

- la date d'écriture du code. Généralement, moi le premier, je recycle énormément de code, donc un projet de 2015 peuvent avoir des lignes de code avec un marqueur temps de 2010. Pourquoi ? parce que j'ai importé une collection de procédure ou autre fait à cette époque... A moins que le développeur soit parano ou s'attendait à cela, il n'a peut-être pas ré-indenter TOUT son code, donc le timecode est toujours celui d'origine. Or si il est dans une boite depuis 2015, il ne peut pas avoir produit du code de 2010...

Tout le code source a été écrit en 8 mois, sur une période cohérente, je n'ai pas identifier d'import de collection de procédure ou autre.

- ensuite j'essaierai de prouver un % de similitude. un copier/coller va donc laisser le même nom de variable, la même aération de code, etc...

J'ai identifié quelques "copier-coller" avec 100% de similitudes par rapport au code original.

- enfin nous sommes en constante amélioration. Un code produit en 2010 sera différent de 2015. Partant de ce postulat, je rechercherais un "bug" dans le code de 2010. Et si je le retrouve en 2015 exactement au même endroit, alors un soupçon peut émaner...

C'est déjà le cas. Une fonction spécifique à Windev utilisé à l'époque de réalisation du code original est présente dans le code "à analyser", alors que ce dernier a été réalisé quelques années plus tard.

[Ry_Yo]

Au cas où....

Concernant le timecode, je ne sais pas si vous connaissais la fonction avancé de recherche de WinDev :



menu édition / rechercher les modifications

Cela permet de balayer tout le projet. Il suffira simplement dans votre cas de prendre la période adéquat.

Ensuite si le développeur n'utilisait pas le GDS, et qu'il a pris le risque d'importer des fenêtres de l'ancien projet pour ne pas se "taper" toutes les procédures locales, alors le "versioning" des fenêtres est accessible :



menu fichier / Versions...

Cela permet déjà d'être exhaustif sur la période de création de tout ça.