Prêt pour le daily de demain les pisseurs de code ?

Le 09 février 2021 à 10:56:57 Pierre_Aronnax a écrit :
Travailler au chaud chez soi pendant qu'il neige.

J'suis en bretagne en ce moment, aussi

Le 09 février 2021 à 11:12:43 ethyl-acetate a écrit :

Le 09 février 2021 à 10:56:57 Pierre_Aronnax a écrit :
Travailler au chaud chez soi pendant qu'il neige.

J'suis en bretagne en ce moment, aussi

Tu n'es pas sensé être à l'Est?

Bon la neige est nulle par contre ca ne va pas tenir

Putain le merge monstrueux que j'ai à faire

Le 09 février 2021 à 11:21:38 Pierre_Aronnax a écrit :

Le 09 février 2021 à 11:12:43 ethyl-acetate a écrit :

Le 09 février 2021 à 10:56:57 Pierre_Aronnax a écrit :
Travailler au chaud chez soi pendant qu'il neige.

J'suis en bretagne en ce moment, aussi

Tu n'es pas sensé être à l'Est?

Bon la neige est nulle par contre ca ne va pas tenir

Je bouge pas mal.
Oui, pas de quoi passer 3 pattes à un canard.

Le 08 février 2021 à 16:45:58 UnaryOperator a écrit :

Le 08 février 2021 à 15:32:02 ethyl-acetate a écrit :
si je gere bien demain je pourrai me la couler assez douce en faisant un peu de tests/clean code

Moi je suis sur le debug d'une lib tierce utilisée par la communauté qui à partir d'annotations, génère un contexte pour de la documentation d'API.
Tout ceci se fait via réflection et via récursivité, et la lib part en boucle infinie

Je debuggue et j'essaie de corriger, à mon avis j'en ai pour 2-3 jours

Y'a un ticket ouvert depuis 6 mois, et le créateur de la lib a lui-même mis dans sa doc qu'il "peut" arriver des boucles infinies

Bon ben c'est corrigé

Les gens qui font de la récursivité, qui créent plein de grappes d'objets dans les différents noeuds... mais qui recréent ces mêmes objets à chaque étape de la récursion où ils en ont besoin au lieu de les réutiliser (du coup memory leak => le GC clean la mémoire => boucle infinie ).

Le 09 février 2021 à 12:54:11 UnaryOperator a écrit :

Le 08 février 2021 à 16:45:58 UnaryOperator a écrit :

Le 08 février 2021 à 15:32:02 ethyl-acetate a écrit :
si je gere bien demain je pourrai me la couler assez douce en faisant un peu de tests/clean code

Moi je suis sur le debug d'une lib tierce utilisée par la communauté qui à partir d'annotations, génère un contexte pour de la documentation d'API.
Tout ceci se fait via réflection et via récursivité, et la lib part en boucle infinie

Je debuggue et j'essaie de corriger, à mon avis j'en ai pour 2-3 jours

Y'a un ticket ouvert depuis 6 mois, et le créateur de la lib a lui-même mis dans sa doc qu'il "peut" arriver des boucles infinies

Bon ben c'est corrigé

Les gens qui font de la récursivité, qui créent plein de grappes d'objets dans les différents noeuds... mais qui recréent ces mêmes objets à chaque étape de la récursion où ils en ont besoin au lieu de les réutiliser (du coup memory leak => le GC clean la mémoire => boucle infinie ).

GG ! c'est toujours intéressant je trouve de bosser sur des libs d'une taille aussi importante

Le 09 février 2021 à 13:49:13 ethyl-acetate a écrit :

Le 09 février 2021 à 12:54:11 UnaryOperator a écrit :

Le 08 février 2021 à 16:45:58 UnaryOperator a écrit :

Le 08 février 2021 à 15:32:02 ethyl-acetate a écrit :
si je gere bien demain je pourrai me la couler assez douce en faisant un peu de tests/clean code

Moi je suis sur le debug d'une lib tierce utilisée par la communauté qui à partir d'annotations, génère un contexte pour de la documentation d'API.
Tout ceci se fait via réflection et via récursivité, et la lib part en boucle infinie

Je debuggue et j'essaie de corriger, à mon avis j'en ai pour 2-3 jours

Y'a un ticket ouvert depuis 6 mois, et le créateur de la lib a lui-même mis dans sa doc qu'il "peut" arriver des boucles infinies

Bon ben c'est corrigé

Les gens qui font de la récursivité, qui créent plein de grappes d'objets dans les différents noeuds... mais qui recréent ces mêmes objets à chaque étape de la récursion où ils en ont besoin au lieu de les réutiliser (du coup memory leak => le GC clean la mémoire => boucle infinie ).

GG ! c'est toujours intéressant je trouve de bosser sur des libs d'une taille aussi importante

C'est souvent mal codé
J'en ai vu une avec des classes de 5000 lignes de code. Et des bugs liés à leur design

Le 09 février 2021 à 14:07:08 UnaryOperator a écrit :

Le 09 février 2021 à 13:49:13 ethyl-acetate a écrit :

Le 09 février 2021 à 12:54:11 UnaryOperator a écrit :

Le 08 février 2021 à 16:45:58 UnaryOperator a écrit :

Le 08 février 2021 à 15:32:02 ethyl-acetate a écrit :
si je gere bien demain je pourrai me la couler assez douce en faisant un peu de tests/clean code

Moi je suis sur le debug d'une lib tierce utilisée par la communauté qui à partir d'annotations, génère un contexte pour de la documentation d'API.
Tout ceci se fait via réflection et via récursivité, et la lib part en boucle infinie

Je debuggue et j'essaie de corriger, à mon avis j'en ai pour 2-3 jours

Y'a un ticket ouvert depuis 6 mois, et le créateur de la lib a lui-même mis dans sa doc qu'il "peut" arriver des boucles infinies

Bon ben c'est corrigé

Les gens qui font de la récursivité, qui créent plein de grappes d'objets dans les différents noeuds... mais qui recréent ces mêmes objets à chaque étape de la récursion où ils en ont besoin au lieu de les réutiliser (du coup memory leak => le GC clean la mémoire => boucle infinie ).

GG ! c'est toujours intéressant je trouve de bosser sur des libs d'une taille aussi importante

C'est souvent mal codé
J'en ai vu une avec des classes de 5000 lignes de code. Et des bugs liés à leur design

Tu maintiens des libs / repos toi même ou pas du tout ?

Le 09 février 2021 à 14:12:13 ethyl-acetate a écrit :

Le 09 février 2021 à 14:07:08 UnaryOperator a écrit :

Le 09 février 2021 à 13:49:13 ethyl-acetate a écrit :

Le 09 février 2021 à 12:54:11 UnaryOperator a écrit :

Le 08 février 2021 à 16:45:58 UnaryOperator a écrit :

Le 08 février 2021 à 15:32:02 ethyl-acetate a écrit :
si je gere bien demain je pourrai me la couler assez douce en faisant un peu de tests/clean code

Moi je suis sur le debug d'une lib tierce utilisée par la communauté qui à partir d'annotations, génère un contexte pour de la documentation d'API.
Tout ceci se fait via réflection et via récursivité, et la lib part en boucle infinie

Je debuggue et j'essaie de corriger, à mon avis j'en ai pour 2-3 jours

Y'a un ticket ouvert depuis 6 mois, et le créateur de la lib a lui-même mis dans sa doc qu'il "peut" arriver des boucles infinies

Bon ben c'est corrigé

Les gens qui font de la récursivité, qui créent plein de grappes d'objets dans les différents noeuds... mais qui recréent ces mêmes objets à chaque étape de la récursion où ils en ont besoin au lieu de les réutiliser (du coup memory leak => le GC clean la mémoire => boucle infinie ).

GG ! c'est toujours intéressant je trouve de bosser sur des libs d'une taille aussi importante

C'est souvent mal codé
J'en ai vu une avec des classes de 5000 lignes de code. Et des bugs liés à leur design

Tu maintiens des libs / repos toi même ou pas du tout ?

Non ça demande beaucoup de temps.

Par contre j'en corrige assez souvent quand je vois des problèmes, généralement ça met plus longtemps de se mettre dans la configuration du problème (use case) plutôt que de faire la correction. C'est normal en tant que dev d'y contribuer quand on le peut, surtout si c'est bloquant dans notre programme.

Par contre quand je vois des dev qui s'arrêtent au moindre souci, c'est bien dommage.

Le 09 février 2021 à 14:18:32 UnaryOperator a écrit :

Le 09 février 2021 à 14:12:13 ethyl-acetate a écrit :

Le 09 février 2021 à 14:07:08 UnaryOperator a écrit :

Le 09 février 2021 à 13:49:13 ethyl-acetate a écrit :

Le 09 février 2021 à 12:54:11 UnaryOperator a écrit :

Le 08 février 2021 à 16:45:58 UnaryOperator a écrit :

Le 08 février 2021 à 15:32:02 ethyl-acetate a écrit :
si je gere bien demain je pourrai me la couler assez douce en faisant un peu de tests/clean code

Moi je suis sur le debug d'une lib tierce utilisée par la communauté qui à partir d'annotations, génère un contexte pour de la documentation d'API.
Tout ceci se fait via réflection et via récursivité, et la lib part en boucle infinie

Je debuggue et j'essaie de corriger, à mon avis j'en ai pour 2-3 jours

Y'a un ticket ouvert depuis 6 mois, et le créateur de la lib a lui-même mis dans sa doc qu'il "peut" arriver des boucles infinies

Bon ben c'est corrigé

Les gens qui font de la récursivité, qui créent plein de grappes d'objets dans les différents noeuds... mais qui recréent ces mêmes objets à chaque étape de la récursion où ils en ont besoin au lieu de les réutiliser (du coup memory leak => le GC clean la mémoire => boucle infinie ).

GG ! c'est toujours intéressant je trouve de bosser sur des libs d'une taille aussi importante

C'est souvent mal codé
J'en ai vu une avec des classes de 5000 lignes de code. Et des bugs liés à leur design

Tu maintiens des libs / repos toi même ou pas du tout ?

Non ça demande beaucoup de temps.

Par contre j'en corrige assez souvent quand je vois des problèmes, généralement ça met plus longtemps de se mettre dans la configuration du problème (use case) plutôt que de faire la correction. C'est normal en tant que dev d'y contribuer quand on le peut, surtout si c'est bloquant dans notre programme.

Par contre quand je vois des dev qui s'arrêtent au moindre souci, c'est bien dommage.

J'ai un de mes meilleurs potes qui tient un plugin qu'il a fait pour dokuwiki depuis qu'il a 15 ans il a encore des PR aujourd'hui.

Le 09 février 2021 à 14:38:53 ethyl-acetate a écrit :
J'pense que les TDD auraient permis à ma boîte d'écrire un code back plus clean

C'est sûr, mais ça ne reste qu'une méthodologie.

Le TDD ça ne s'applique pas partout (typiquement un algorithme de tri etc... tu vas pas t'amuser à écrire step-by-step la méthode ).

En revanche il faut s'imposer des objectifs techniques : au moins 85% de couverture sur du nouveau code, éviter les codes smell, mettre en place des conventions (code formater, linter, checkstyle etc..), zero-bug policy etc..

Et encore en TDD il y a plusieurs écoles : London school vs Chicago school. Il faut voir ce qui se prête le mieux à ton projet.

Le 09 février 2021 à 14:42:09 UnaryOperator a écrit :

Le 09 février 2021 à 14:38:53 ethyl-acetate a écrit :
J'pense que les TDD auraient permis à ma boîte d'écrire un code back plus clean

C'est sûr, mais ça ne reste qu'une méthodologie.

Le TDD ça ne s'applique pas partout (typiquement un algorithme de tri etc... tu vas pas t'amuser à écrire step-by-step la méthode ).

En revanche il faut s'imposer des objectifs techniques : au moins 85% de couverture sur du nouveau code, éviter les codes smell, mettre en place des conventions (code formater, linter, checkstyle etc..), zero-bug policy etc..

Et encore en TDD il y a plusieurs écoles : London school vs Chicago school. Il faut voir ce qui se prête le mieux à ton projet.

J'en ai discuté un peu avec l'equipe, pour le CTO les tests d'integration suffisent au niveau API, pas besoin de tests unitaires pour chaque entité/service/helper/...

Le 09 février 2021 à 15:23:44 ethyl-acetate a écrit :

Le 09 février 2021 à 14:42:09 UnaryOperator a écrit :

Le 09 février 2021 à 14:38:53 ethyl-acetate a écrit :
J'pense que les TDD auraient permis à ma boîte d'écrire un code back plus clean

C'est sûr, mais ça ne reste qu'une méthodologie.

Le TDD ça ne s'applique pas partout (typiquement un algorithme de tri etc... tu vas pas t'amuser à écrire step-by-step la méthode ).

En revanche il faut s'imposer des objectifs techniques : au moins 85% de couverture sur du nouveau code, éviter les codes smell, mettre en place des conventions (code formater, linter, checkstyle etc..), zero-bug policy etc..

Et encore en TDD il y a plusieurs écoles : London school vs Chicago school. Il faut voir ce qui se prête le mieux à ton projet.

J'en ai discuté un peu avec l'equipe, pour le CTO les tests d'integration suffisent au niveau API, pas besoin de tests unitaires pour chaque entité/service/helper/...

C'est pas une bonne approche, sachant que ces tests sont :
- plus coûteux à mettre en place / à corriger (moins proche du dev car s'exécutent sur un environnement déployé)
- pas forcément adaptés : 80% des bugs correspondent à 20% du code (loi 80-20 https://dzone.com/articles/applying-8020-rule-software )

Il faudrait en premier mettre en place les TU avant les tests IT. Quitte à réajuster le "sweet spot" du coverage rate, et en testant en priorité le code responsable des règles métier (domain objects, services..).

Bon finalement la meuf de mailto:Th@l€$ c'est leur branche SSII et apparemment mon profil les intéresse mais pour eux si on rentre faut être dév en bas de l'échelle mais avec "prise de responsabilité rapide"

Bref de la merde sûrement aucun intérêt de bouger pour être esclave en SSII.

Le 09 février 2021 à 16:19:22 magicorange a écrit :
Trop de TDD tue le TDD

https://www.youtube.com/watch?v=jxBmKvS7lAo je commence à m'intéresser au domaine