/* Topic des codeurs [8] */

:!pakman · Le 26/02/2013, à 21:52

The Uploader a écrit :

J'adore quand tu postes grim'.
*lit et sauvegarde tous les liens*

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

grim7reaper · Le 26/02/2013, à 22:19

Rolinh a écrit :

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

Merci

Rolinh a écrit :

Sinon, notre nouveau jouet en officialisé.

Joli
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'.
*lit et sauvegarde tous les liens*
C'est clair, grim' est un vrai puit de science

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.

Mindiell · Le 27/02/2013, à 17:09

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...

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

grim7reaper · Le 28/02/2013, à 08:56

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.

sweetly · Le 28/02/2013, à 09:07

grim7reaper a écrit :

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

Coupaing

Mindiell · Le 28/02/2013, à 09:35

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)

Epehj · Le 28/02/2013, à 10:25

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.

The Uploader · Le 28/02/2013, à 10:28

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)

Epehj · Le 28/02/2013, à 11:25

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.

grim7reaper · Le 28/02/2013, à 11:55

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)

sweetly · Le 28/02/2013, à 13:36

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

grim7reaper · Le 28/02/2013, à 16:05

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

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

:!pakman · Le 28/02/2013, à 17:00

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

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

grim7reaper · Le 28/02/2013, à 17:22

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 ?
(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.

The Uploader · Le 28/02/2013, à 17:45

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. ).

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

:!pakman · Le 28/02/2013, à 17:54

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)

Mindiell · Le 28/02/2013, à 22:35

:!pakman a écrit :

Vous en pensez quoi de Dart ?

Dart a écrit :

Dart can be compiled to JavaScript

Pylades · Le 28/02/2013, à 23:07

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 ?

The Uploader · Le 28/02/2013, à 23:08

Non, non. Surtout le premier. O_o

:!pakman · Le 01/03/2013, à 00:30

C'est clair

Epehj · Le 01/03/2013, à 09:36

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)

Dr Le Rouge · Le 01/03/2013, à 13:13

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.

Mindiell · Le 01/03/2013, à 14:31

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 (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 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

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

Epehj · Le 01/03/2013, à 14:47

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.

Mindiell · Le 01/03/2013, à 15:31

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"

Ubuntu-fr

Navigation

Liens de recherche

Annonce

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pied de page des forums