Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#726 Le 26/02/2013, à 21:52

:!pakman

Re : /* Topic des codeurs [8] */

The Uploader a écrit :

J'adore quand tu postes grim'. smile

*lit et sauvegarde tous les liens*

C'est clair, grim' est un vrai puit de science cool
Je me régale à chaque fois smile


...

Hors ligne

#727 Le 26/02/2013, à 22:19

grim7reaper

Re : /* Topic des codeurs [8] */

Rolinh a écrit :

@grim: intéressant tes posts et liens (comme d'hab en fait quoi)

Merci smile

Rolinh a écrit :

Sinon, notre nouveau jouet en officialisé. smile

Joli smile
Surtout niveau conso’, c’est impressionnant.
Moi en ce moment je peux avoir accès à ça ou mieux : ça.
Un monstre… 11e au top500 de novembre dernier, number one en France.
Par contre niveau conso’…



:!pakman a écrit :
The Uploader a écrit :

J'adore quand tu postes grim'. smile

*lit et sauvegarde tous les liens*

C'est clair, grim' est un vrai puit de science cool

Je suis bien content que ça serve.
Mais n’exagérons rien. Je n’ai rien inventé, je ne fais que lire et apprendre chaque jour.
Je ne suis pas un puits de science, je puise dedans.

Hors ligne

#728 Le 27/02/2013, à 17:09

Mindiell

Re : /* Topic des codeurs [8] */

Mindiell a écrit :

Pitite question de TDD :
Je me suis p'tet laissé un poil dépassé par mon code, et j'ai l'impression que mes tests servent plus à tester mon code que mon code à résoudre mes tests. Vaut-il mieux que je mette tout de côté et que je refasse mes tests un par un, puis mon code à partir de ce que j'ai déjà codé ou bien tant pis, je continue as is, mes tests me servant tout de même pour la non régression ?

Python owned... hmm

Personne n'a vu mon message ou bien personne ne "sait / s'intéresse / veut répondre..." ? wink

Hors ligne

#729 Le 28/02/2013, à 08:56

grim7reaper

Re : /* Topic des codeurs [8] */

Pour ma part c’est « ne sais pas ».
Pour le TDD, j‘en suis encore à essayer de le mettre en pratique donc je suis pas super bien placé pour donner des conseils.

Hors ligne

#730 Le 28/02/2013, à 09:07

sweetly

Re : /* Topic des codeurs [8] */

grim7reaper a écrit :

Moi en ce moment je peux avoir accès à ça ou mieux : ça.

Coupaing smile

Hors ligne

#731 Le 28/02/2013, à 09:35

Mindiell

Re : /* Topic des codeurs [8] */

grim7reaper a écrit :

Pour ma part c’est « ne sais pas ».
Pour le TDD, j‘en suis encore à essayer de le mettre en pratique donc je suis pas super bien placé pour donner des conseils.

Bon, ben j'ai tout archivé dans un coin et repris ça proprement.
Et en plus, j'ai commencé à utiliser des greffons pour Gedit qui est, de base, assez... basique justement.
Voire même je suis en train d'installer gvim (oui, je suis pas fana fana du terminal pur)

Hors ligne

#732 Le 28/02/2013, à 10:25

Epehj

Re : /* Topic des codeurs [8] */

Bonjour les codeurs,

J'ai besoin de votre feedback ; lorsque vous utilisez des outil d'analyse de code, quelles sont les métriques les plus utiles pour vous et pourquoi ? Je dois mettre ça en place mais c'est clairement pas mon domaine donc je suis un peu perdu.


Linux user #447629 - Ubuntu user # 21770
C'est en sciant que Léonard devint scie

Hors ligne

#733 Le 28/02/2013, à 10:28

The Uploader

Re : /* Topic des codeurs [8] */

Sonar a l'air pas mal.

Après, ça sert à rien tout seul.

Une des métriques serait par exemple le test coverage (inutile si utilisée seule).

Dernière modification par The Uploader (Le 28/02/2013, à 10:32)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#734 Le 28/02/2013, à 11:25

Epehj

Re : /* Topic des codeurs [8] */

Niveau outil je connais sonar, mais je me demande vraiment lesquelles vous intéressent vous.

En gros là je fais un rapport, et dedans je pensais mettre un petit paragraphe «Les métriques les plus utiles» et expliquer pourquoi elles me paraissent utiles; pour le moment, j'en ai 6 :
- complexité cyclomatique et code coverage via tests unitaires
- backlogging : pour voir l'avancement (enfin plutôt le nombre de corrections) d'une tâche
- le respect des normes
- le nombre de lignes de code, à rapporter au nombre de devs sur une tâche. Ça peut donner une idée de la productivité
- ratio ligne de code/commentaires, pour savoir si le code est facilement maintenable
- dépendances cycliques, pour voir s'il y a des problèmes d'architecture

A savoir que là où je suis, les tests unitaires ils connaissent pas, le svn sert de dossier d'archivage, l'intégration continue c'est pareil c'est inexistant…donc je dois bien expliquer les choses pour avoir une chance de les faire changer.


Linux user #447629 - Ubuntu user # 21770
C'est en sciant que Léonard devint scie

Hors ligne

#735 Le 28/02/2013, à 11:55

grim7reaper

Re : /* Topic des codeurs [8] */

Pas encore lu, mais ça semble intéressant et plutôt complet.

@sweetly : tu fais tourner quoi là-dessus ?

Dernière modification par grim7reaper (Le 28/02/2013, à 13:23)

Hors ligne

#736 Le 28/02/2013, à 13:36

sweetly

Re : /* Topic des codeurs [8] */

@grim : modèles de géophysique (atmosphère, océan, etc)

Hors ligne

#737 Le 28/02/2013, à 16:05

grim7reaper

Re : /* Topic des codeurs [8] */

Ok, je fais tourner un modèle aussi (biogéochimique) smile

Dernière modification par grim7reaper (Le 28/02/2013, à 16:06)

Hors ligne

#738 Le 28/02/2013, à 17:00

:!pakman

Re : /* Topic des codeurs [8] */

Vous en pensez quoi de Dart ?
C'est développé par Google, donc forcément génial, non ? tongue
(Oui, je suis un fanboy sévèrement atteint ^^)

Dernière modification par :!pakman (Le 28/02/2013, à 17:01)


...

Hors ligne

#739 Le 28/02/2013, à 17:22

grim7reaper

Re : /* Topic des codeurs [8] */

Je ne fais pas de dev‘ web donc j’en ai pas trop l’utilité. Du coup, je connais juste de nom donc je vais éviter de donner un avis.

:!pakman a écrit :

C'est développé par Google, donc forcément génial, non ? tongue
(Oui, je suis un fanboy sévèrement atteint ^^)

Google c’est pas synonyme de génial hein.
Genre Go. Ça n’a rien de révolutionnaire et ça n’apporte pas grand-chose en plus par rapport à l’existant je trouve (ça veux pas dire que c’est mauvais, mais ça casse pas non plus trois pattes à un canard). Après c’est peut-être parce que je connais pas assez le langage.

Hors ligne

#740 Le 28/02/2013, à 17:45

The Uploader

Re : /* Topic des codeurs [8] */

Tout ce que propose Darts, de ce que je vois, tu l'as tout autant ailleurs.

Et puis si j'dois utiliser une espèce de javascript qui m'donne pas envie de me tuer, j'utiliserais coffeescript, qui est moins bavard que darts (et j'ai déjà fait du coffeescript. On se tape pas des 'var' à chaque création de variable qui servent à rien. Comme en ActionScript d'ailleurs. neutral ).

Dernière modification par The Uploader (Le 28/02/2013, à 17:51)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#741 Le 28/02/2013, à 17:54

:!pakman

Re : /* Topic des codeurs [8] */

Coffeescript, j'en ai vaguement entendu parler. Je vais me renseigner la dessus...
En passant, je crois qu'en js tu n'est pas obligé de mettre le var, bien que ce soit recommandé.

Edit : Dart gère peut être mieux la POO que Javascript, je vais regarder ça...

Dernière modification par :!pakman (Le 28/02/2013, à 18:15)


...

Hors ligne

#742 Le 28/02/2013, à 22:35

Mindiell

Re : /* Topic des codeurs [8] */

:!pakman a écrit :

Vous en pensez quoi de Dart ?

Dart a écrit :

Dart can be compiled to JavaScript

roll

Hors ligne

#743 Le 28/02/2013, à 23:07

Pylades

Re : /* Topic des codeurs [8] */

Epehj a écrit :

- le nombre de lignes de code, à rapporter au nombre de devs sur une tâche. Ça peut donner une idée de la productivité
- ratio ligne de code/commentaires, pour savoir si le code est facilement maintenable

Il n’y a que moi que ça choque et qui y voit de mauvais indicateurs ?


“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Hors ligne

#744 Le 28/02/2013, à 23:08

The Uploader

Re : /* Topic des codeurs [8] */

Non, non. Surtout le premier. O_o


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#745 Le 01/03/2013, à 00:30

:!pakman

Re : /* Topic des codeurs [8] */

C'est clair neutral


...

Hors ligne

#746 Le 01/03/2013, à 09:36

Epehj

Re : /* Topic des codeurs [8] */

Bah expliquez moi, si je demande en précisant que c'est pas mon domaine, c'est pas pour rien. Juste me dire que c'est nul ça me fera pas avancer.

-- edit
Bon mea culpa, je me suis levé du mauvais pied.
Pour être plus précis, et surement parce que j’emploie la mauvaise terminologie :

- le nombre de lignes de code, à rapporter au nombre de devs sur une tâche. Ça peut donner une idée de la productivité

C'est en fait pour identifier les «points chauds». Le code est divisé en module, genre module1, module2, module3.
Un premier build est fait, module1 a X lignes et le code ne vient que d'un dev et module2 en a Y par 2devs.
Deuxième build, et là on voit que module1 est passé à X*2 lignes, mais avec 3 devs dessus dont un qui était, sur le build précédent, sur le module 2, module 3 a pas changé.
Troisième build, module1 a pas bougé, module 2 a perdu des lignes et on voit que le dev qui était sur module 2 et qui est passé sur module1 est de nouveau sur module2. module3 a gagné quelques lignes, et on voit que le dev de module1 est passé sur module3.

Du coup j'ai l'impression qu'on voir ou s'est située l'activité.
Mais je sais pas si je suis clair.

Est ce que vous pouvez m'expliquer pourquoi ce sont de (très, d'après vos réactions) mauvais indicateurs ?

Dernière modification par Epehj (Le 01/03/2013, à 11:34)


Linux user #447629 - Ubuntu user # 21770
C'est en sciant que Léonard devint scie

Hors ligne

#747 Le 01/03/2013, à 13:13

Dr Le Rouge

Re : /* Topic des codeurs [8] */

Elisp bidouillé en attendant mon avion :

(defun my-insert-symmetric-symbols(left right)
  "Inserts a pair of symbol and moves cursor between them or, if
  a region is selected, puts them around it."
  (if (region-active-p)
      (progn
        (setq begin (region-beginning) end (region-end))
        (goto-char end)
        (insert right)
        (goto-char begin)
        (insert left)
        )
    (progn
      (insert left right)
      (backward-char (length right))
      )
    )
  )

J'ai maintenant toute une série de fonctions basées sur celle-ci, par exemple :

(defun my-insert-parenthesis()
  "Inserts () and) moves the cursor in between."
  (interactive)
  (my-insert-symmetric-symbols "(" ")")
)

que j'ai mappée sur "C-)". Si une partie du texte est sélectionnée, "C-)" place des parenthèses autour. Si aucun texte n'est sélectionné, ça insère "()" et place le curseur entre les deux. D'autres fonctions similaires font que, de la même façon, "C-]' met des crochets, "C-}" des accolades, "C-\"" met des guillemets…

Ça me sera bien utile quand j'écris du LaTeX pour mettre des parenthèses/accolades/"\big)" et autres dans mes équations.


C'est deux suites de Cauchy qui veulent aller à la soirée 'no limit'. Hélas, à l'entrée le videur leur dit : "désolé, c'est complet !".
mon site perso (π²/6.fr) et mon blog

Hors ligne

#748 Le 01/03/2013, à 14:31

Mindiell

Re : /* Topic des codeurs [8] */

Epehj a écrit :

Est ce que vous pouvez m'expliquer pourquoi ce sont de (très, d'après vos réactions) mauvais indicateurs ?

Je pense que c'est bien la terminologie qui coince.
Parce que par "productivité", les gens qui produisent ont forcément l'impression d'être fliqués :
- dev1 est-il assez productif ?
- dev2 est très productif, pourquoi dev1 et dev3 non ?

On peut en arriver au stakhanovisme, ce qui n'est pas forcément le but recherché.

D'un autre côté, un dirigeant avec ces chiffres sera surement tenté de les exploiter comme ça. Par contre, un chef de projet, si on lui explique le concept, pourra surement en faire meilleur usage, du genre : "Eh les gars, vous avez bien travaillé, mais là on a vraiment besoin que vous vous penchiez sur tel tâche !" Et il pourra "vérifier" que c'est fait.

Par contre, il faut conserver un "différentiel absolu" et encore ce n'est pas si simple : Comment savoir que la personne qui a bossé trois jours pour rajouter 6 lignes est vraiment productive, car elle avait d'abord ajouté 150 lignes, mais a optimisé et simplifié tout ça ?


Idem, à mon sens, pour les commentaires : Tu risques d'avoir des commentaires bidons juste pour ne pas être dans le rouge.

Donc bien penser à préciser que ce sont des indicateurs, non des vérités wink (oui, tu le sais toi, mais pas forcément ceusses qui viendront après toi)


===================

Epehj a écrit :

mais je me demande vraiment lesquelles vous intéressent vous.
- complexité cyclomatique et code coverage via tests unitaires
- backlogging : pour voir l'avancement (enfin plutôt le nombre de corrections) d'une tâche
- le respect des normes
- le nombre de lignes de code, à rapporter au nombre de devs sur une tâche. Ça peut donner une idée de la productivité
- ratio ligne de code/commentaires, pour savoir si le code est facilement maintenable
- dépendances cycliques, pour voir s'il y a des problèmes d'architecture

Alors :
- complexité cyclomatique : je ne connaissais pas. Je ne sais pas ce que ça vaut, ça ne m'intéresse pas forcément
- code coverage : Si tests unitaires, je trouve ça absolument indispensable (forcément)
- backlogging : J'ai du mal à voir ce que ça représente, tu peux expliciter ?
- respect des normes : important, intéressant à avoir sous le coude
- productivité : pas d'intérêt pour moi, je gère le "travail fait" par rapport aux tickets ou au retour client, risque de dérive : je me fiche de savoir qui l'a fait tant que c'est fait wink Et si tu codes en binôme, un dev ne fera "rien" certains jours
- ratio de commentaires : risque de dérive et de se retrouver avec des commentaires pour avoir un bon ratio. Chiffre qui ne m'intéresse pas (en plus la "norme" python demande des docstrings et j'ai tendance à un peu les bâcler au départ)
- dépendance cyclique : m'intéresse pas

La deuxième chose, c'est surtout, je dirais, la méthode de correction de ces valeurs. Si tu ne fais rien, tu auras des commentaires bidons par exemple.
Il est donc important de faire ses stats, et d'en discuter après avec les intéressés (dev et responsables). Et de voir les impacts au long terme. Si on voit qu'une mesure est mauvaise et que la corriger ne fait pas un bien mesurable au projet, c'est qu'il y a un problème : soit c'est inutile, soit c'est mal corrigé ou mesuré.

Voilà, voilà, il y aurait beaucoup d'autres choses à dire, mais je dois bosser un peu wink

Dernière modification par Mindiell (Le 01/03/2013, à 14:42)

Hors ligne

#749 Le 01/03/2013, à 14:47

Epehj

Re : /* Topic des codeurs [8] */

Merci pour la réponse.
Oui ces métriques ne seront là que pour notre équipe, pour les besoins des marketeux ou des dirigeants on devrait mettre autre chose en place, mais je ne sais pas encore quoi.
C'est surtout la tendance des métriques en fait qui va m'intéresser, rarement la métrique seule.

Pour les commentaires, c'est surtout pour dégager les classes suspicieuses : si on a un fichier avec 500 lignes et 3lignes de commentaires, ça va nous mettre la puce à l'oreille et on va jeter un œil. Si l'algo se lit, on comprendra qu'il n'y ait pas forcément besoin de commenter. C'est l'idée.
Ces métriques ne serviront pas a punir/fliquer les devs, mais juste à donner à l'équipe un feedback.


Linux user #447629 - Ubuntu user # 21770
C'est en sciant que Léonard devint scie

Hors ligne

#750 Le 01/03/2013, à 15:31

Mindiell

Re : /* Topic des codeurs [8] */

Epehj a écrit :

Ces métriques ne serviront pas a punir/fliquer les devs, mais juste à donner à l'équipe un feedback.

Voilà, des métriques par l'équipe et pour l'équipe c'est bien.
Mais surtout, c'est faire les apprentissages par petite touche. Les tests unitaires ne servent pas à grand chose si tu ne dev pas en mode TDD par exemple.

En tout cas, bon courage, c'est toujours intéressant de confronter les belles théories et les pratiques "ancestrales" wink

Hors ligne