Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 25 sur 182 PremièrePremière ... 1517181920212223242526272829303132333575125 ... DernièreDernière
Affichage des résultats 721 à 750 sur 5434
  1. #721
    Citation Envoyé par William Vaurien Voir le message
    En ce qui concerne VI et consort, il y a sûrement moyen d'obtenir un truc quasi équivalent à un IDE moderne, mais l'effort nécessaire pour avoir ne serait-ce que le minimum vitale ne me parait pas vraiment en valoir le coup.
    Et pour ceux qui ne jurent que par les raccourcis claviers ('si si regarde pour effacer 23 lignes je tape 23 d c'est super rapide !!!') il y a même des plugins exprès dans les IDE jetbrains.

    Pour en revenir sur la différence d'esprit et de vision sur la programmation en général, je me rappel que pendant mes études (IUT puis DESS de 1998-2003) , aucun prof ne nous a parlé de qualité de code, de bonnes pratiques ou de tests unitaires. Le manifeste agile circulait dans la classe pendant mes dernières années de fac, mais j'avais pas vraiment compris de quoi il s'agissait...
    Si certains profs insistaient sur le découpage en petits blocs, beaucoup d'autres voulaient de la "bonne grosse méthode qui fait tout". Je m'étais pris plusieurs fois des réflexions à ce sujet.
    Je ne savais même pas ce qu'était un gestionnaire de version en sortant de la fac, et le seul prof qui nous a montré un IDE était un intervenant externe qui nous a sorti Eclipse. Et en 2003 c'était déjà tout pourri Eclipse, j'avais déjà découvert Intellij !

    Et faire du refactoring avec nedit (époque IUT) ou autre éditeur de texte basique, ou même un vi / emacs bien maîtrisé c'est pénible et dangereux comme renommer une fonction ou en changer les paramètres ! Naviguer dans le code aussi !
    La - fausse - solution: garder les choses le plus simples possible et éviter la 'prolifération' des petites méthodes...

    Du coup je me suis pris un grosse claque lors de mon premier job, et j'ai bien apprécié des outils comme 'checkstyle' qui valorisait la brièveté (un peu trop parfois !) avec des warnings dès qu'une méthode fait plus de 20 lignes ou quand la complexité (nombre d'instruction de contrôle/boucle) est trop forte.
    True reconnaissent True
    Attention, un Max_well peut en cacher un autre
    Equipe Highlander La Rache

  2. #722
    Mouais, perso je suis sous SublimeText, et je fais vachement plus gaffe à la propreté et à l'uniformisation de ce que j'écris (à grand coup de clang-format de préférence, mais aussi simplement en regardant comment le code autour à été écrit) que beaucoup de gens que je connais et qui travaillent toute la journée sous Visual Studio.

    Le problème vient plutôt des personnes que des outils utilisés. Les bonnes pratiques ça s'apprend et ça s'entretient mais ça demande un minimum de volonté et d'effort de la part des développeurs qui devraient plus se préoccuper du confort des gens qui vont relire leur code (potentiellement leur futur eux-même) plutôt que de leur petit confort personnel au moment ou ils l'écrivent.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  3. #723
    Tiens en parlant des vieux souvenirs et des profs pas toujours à jour, je me rappel d'un pote qui avait voulu valider son expérience (il avait foiré son bac mais avait trouvé du taf pendant la fameuse bulle internet) avec une formation AFPA.
    Il apprenait à faire du dev avec Java. Très bien. Sauf qu'il apprenait avec Visual J++. En 2005 ou 2006... alors que cet abomination était morte depuis longtemps.

    Et plus récemment un jeune diplômé est arrivé dans mon équipe (il a du bol: il ne touche pas au vieux monstre écrit en C). Et en discutant avec lui je me rend compte que ses cours de Java (datant de 2012-2015) était basés sur Java 4...
    Son prof disait que c'était pour ne pas 's’embarrasser du superflu' ou un truc du genre...

  4. #724
    Citation Envoyé par William Vaurien Voir le message
    Et faire du refactoring avec nedit (époque IUT) ou autre éditeur de texte basique, ou même un vi / emacs bien maîtrisé c'est pénible et dangereux comme renommer une fonction ou en changer les paramètres ! Naviguer dans le code aussi !
    La - fausse - solution: garder les choses le plus simples possible et éviter la 'prolifération' des petites méthodes...
    Ceci.
    Plus généralement, si c'est risqué de faire du refactoring sur un projet, c'est avant tout un problème d'outils (aussi bien d'édition de code que de validation des changements).

    Citation Envoyé par Lazyjoe Voir le message
    Dans le fond c'est un monde que j'aimerais bien découvrir quand même un jour. Par curiosité.
    Bah déjà aller éditer quelque chose manuellement sur un serveur, c'est juste non (sauf hotfix d'urgence de la mort et test d'une nouvelle config sur un nouveau projet).
    Quand t'as toute ta chaîne en place, c'est quand même un putain de confort de pouvoir coder en local sereinement en déléguant tout le reste au serveur d'intégration.

    Après c'est plus compliqué à mettre en place dans ton cas, vu qu'il n'est pas forcément possible d'avoir des environnements distincts de dev/prod/recette (car gros calcul scientifique qui tache demandant des putains de ressources).

    Citation Envoyé par rOut Voir le message
    je fais vachement plus gaffe à la propreté et à l'uniformisation de ce que j'écris (à grand coup de clang-format de préférence, mais aussi simplement en regardant comment le code autour à été écrit)
    Ah mais c'est essentiel aussi bien évidemment.
    Tout projet qui se respecte doit avoir un outil pour vérifier le style et la syntaxe du code.
    C'est la faute à Arteis

  5. #725
    Citation Envoyé par rOut Voir le message
    Le problème vient plutôt des personnes que des outils utilisés. Les bonnes pratiques ça s'apprend et ça s'entretient mais ça demande un minimum de volonté et d'effort de la part des développeurs
    Le problème c'est que c'est assez subjectif, et qu'il y a souvent des 'guerres de religion' entre ce qui est lisible pour l'un et pas par l'autre. C'est d'autant plus flagrant quand il y a des 'polyglottes' dans les équipes qui 'importent' leurs préférences avec eux.
    Aussi bien au niveau du style que du 'design' du code. Et c'est encore plus prononcé avec l'arrivée du fonctionnel dans les langages objet 'traditionnels'. Entre un dev qui colle des lambda partout, un autre qui fait du code golf et un autre qui ne c'est pas mis à jour c'est parfois compliqué de trouvé le bon degré de ce qui est acceptable ou non.

    Les outils de qualité de code et d'analyse statique ont le gros avantage d'être neutre et de pas trop froisser les egos, au moins pour la partie mise en page et respect de règles élémentaires:
    méthode de 600 lignes, 12 paramètres avec 3 for imbriqués et des switch --> lol no. C'est plus simple quand c'est un robot qui le dit !

    Au niveau des IDE, il y a aussi cette analyse en temps réel qui permet d'éviter pas mal de problème en détectant des erreurs avant même la compilation. Des erreurs aussi bien de bugs potentiels que de design foireux.

    A moins d'être un compilateur vivant, c'est quand même un énorme plus (je sais qu'il existe pas mal de compilateur vivant, mais c'est loin d'être la majorité !) que les éditeurs de texte amélioré ne peuvent pas proposer.

  6. #726
    Citation Envoyé par William Vaurien Voir le message
    Le problème c'est que c'est assez subjectif, et qu'il y a souvent des 'guerres de religion' entre ce qui est lisible pour l'un et pas par l'autre. C'est d'autant plus flagrant quand il y a des 'polyglottes' dans les équipes qui 'importent' leurs préférences avec eux.
    Aussi bien au niveau du style que du 'design' du code. Et c'est encore plus prononcé avec l'arrivée du fonctionnel dans les langages objet 'traditionnels'. Entre un dev qui colle des lambda partout, un autre qui fait du code golf et un autre qui ne c'est pas mis à jour c'est parfois compliqué de trouvé le bon degré de ce qui est acceptable ou non.

    Les outils de qualité de code et d'analyse statique ont le gros avantage d'être neutre et de pas trop froisser les egos, au moins pour la partie mise en page et respect de règles élémentaires:
    méthode de 600 lignes, 12 paramètres avec 3 for imbriqués et des switch --> lol no. C'est plus simple quand c'est un robot qui le dit !

    Au niveau des IDE, il y a aussi cette analyse en temps réel qui permet d'éviter pas mal de problème en détectant des erreurs avant même la compilation. Des erreurs aussi bien de bugs potentiels que de design foireux.

    A moins d'être un compilateur vivant, c'est quand même un énorme plus (je sais qu'il existe pas mal de compilateur vivant, mais c'est loin d'être la majorité !) que les éditeurs de texte amélioré ne peuvent pas proposer.
    go fmt et si t'es pas d'accord, tu es d'accord quand même.
    "Nobody exists on purpose. Nobody belongs anywhere. We're all going to die. Come watch TV." - Morty Smith

  7. #727
    Citation Envoyé par Orhin Voir le message
    Après c'est plus compliqué à mettre en place dans ton cas, vu qu'il n'est pas forcément possible d'avoir des environnements distincts de dev/prod/recette (car gros calcul scientifique qui tache demandant des putains de ressources).
    Bah c'est surtout une question de philosophie. Il n'y a pas de notion de prod ou de recette en soi. Quand un nouvel utilisateur doit utiliser le logiciel de simu, bah c'est à lui de recompiler le tout sur les machines qu'il va utiliser.

    Je suis dans une petite team dissidente qui tente de moderniser un peu le tout pour que ça soit un peu plus "industrialisable", mais beaucoup de gens se demandent à quoi sert ce boulot qui ne fera pas de publis.

    Au quotidien ça donne "- Ce serait quand même plus pratique avec des structures de données pour tout bien ranger !"
    Chef physicien : "Mouais non on ne verra pas clairement ce qui se passe ça va entraîner des confusions. On reste sur le mode actuel où on passe 40 tableaux en paramètres aux grosses fonctions, c'est plus clair comme ça"
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  8. #728
    Citation Envoyé par William Vaurien Voir le message
    Tiens en parlant des vieux souvenirs et des profs pas toujours à jour, je me rappel d'un pote qui avait voulu valider son expérience (il avait foiré son bac mais avait trouvé du taf pendant la fameuse bulle internet) avec une formation AFPA.
    Il apprenait à faire du dev avec Java. Très bien. Sauf qu'il apprenait avec Visual J++. En 2005 ou 2006... alors que cet abomination était morte depuis longtemps.

    Et plus récemment un jeune diplômé est arrivé dans mon équipe (il a du bol: il ne touche pas au vieux monstre écrit en C). Et en discutant avec lui je me rend compte que ses cours de Java (datant de 2012-2015) était basés sur Java 4...
    Son prof disait que c'était pour ne pas 's’embarrasser du superflu' ou un truc du genre...
    Et, euh, c'est vraiment grave ? On a inventé des nouveaux concepts de programmation objet en Java 9 qui rendent obsolète les classes de Java 1 ? Un dev qui a été en cours en 2000 est bon pour la retraite en 2020 ?

  9. #729
    Faire un rapide passage sur les Generics, les lambda et les streams ce serait pas mal. Et éviter d'utiliser des classes périmées aussi (Vector...).
    C'est plus le côté déconnecté qui est grave... comme le fait de ne pas savoir ce qu'est un gestionnaire de source.

    Je sais qu'il y a un vieux débat sur les formations en info: 'sciences de l'informatique vs ingénieur prêt à l'emploi'. Je suis plutôt en faveur de la première approche.

    Par contre rien n'empêche de caser un peu "d'ingénierie de l'informatique" dans un cursus universitaire. Je pense que dans certains cursus c'est déjà le cas, mais pas partout.
    Si je reprends mes 3 années à la fac, il y avait pas mal de cours sympa mais très facultatifs, et très peu de cours de 'comment ça se passe dans la vrai vie'.
    Et le peu qu'il y avait était souvent dispensés par des universitaires qui ne connaissaient pas vraiment 'comment ça se passe dans la vrai vie'...

    Et c'est dommageable pour les étudiants, qui vont se prendre des grosses baffes s'ils font autres chose que de la recherche (ou de l'informatique scientifique) ET pour les entreprises qui pourraient bénéficier d'un savoir faire 'à jour' de leurs nouveaux arrivants, notamment pour bousculer un peu les équipes qui s’encroûtent.

  10. #730
    Citation Envoyé par William Vaurien Voir le message
    un autre qui fait du code golf
    :burnthewitch:

    Citation Envoyé par William Vaurien Voir le message
    Les outils de qualité de code et d'analyse statique ont le gros avantage d'être neutre et de pas trop froisser les egos, au moins pour la partie mise en page et respect de règles élémentaires:
    méthode de 600 lignes, 12 paramètres avec 3 for imbriqués et des switch --> lol no. C'est plus simple quand c'est un robot qui le dit !
    Surtout que pas mal de framework fournissent leur propre fichier de config pour ces outils, ce qui permet de s'assurer d'être en phase avec le reste de la communauté respectant ces "bonnes pratiques".

    Citation Envoyé par Møgluglu Voir le message
    Un dev qui a été en cours en 2000 est bon pour la retraite en 2020 ?
    Si il ne s'est pas mis à niveau et qu'il arrive sur un nouveau projet, il risque quand même d'être largué.

    De toute façon Kotlin > Java peu importe la version.

    Citation Envoyé par Lazyjoe Voir le message
    Bah c'est surtout une question de philosophie. Il n'y a pas de notion de prod ou de recette en soi. Quand un nouvel utilisateur doit utiliser le logiciel de simu, bah c'est à lui de recompiler le tout sur les machines qu'il va utiliser.
    Ouais effectivement dans ce cas c'est compliqué à mettre en place (surtout si t'as plein d'archi à supporter).
    Après tu peux toujours avoir des machines cibles de base sur lesquelles les tests de non régression sont lancés à chaque commit.
    Sachant que pour le coup vous avez une base de test très facile à obtenir avec tous les thésards qui utilisent déjà le soft (alors que généralement les bases de test c'est bien casse-couille à produire).

    Citation Envoyé par Lazyjoe Voir le message
    Je suis dans une petite team dissidente qui tente de moderniser un peu le tout pour que ça soit un peu plus "industrialisable", mais beaucoup de gens se demandent à quoi sert ce boulot qui ne fera pas de publis.

    Au quotidien ça donne "- Ce serait quand même plus pratique avec des structures de données pour tout bien ranger !"
    Chef physicien : "Mouais non on ne verra pas clairement ce qui se passe ça va entraîner des confusions. On reste sur le mode actuel où on passe 40 tableaux en paramètres aux grosses fonctions, c'est plus clair comme ça"
    :patpat:
    C'est la faute à Arteis

  11. #731
    Citation Envoyé par William Vaurien Voir le message
    Le problème c'est que c'est assez subjectif, et qu'il y a souvent des 'guerres de religion' entre ce qui est lisible pour l'un et pas par l'autre. C'est d'autant plus flagrant quand il y a des 'polyglottes' dans les équipes qui 'importent' leurs préférences avec eux.
    Aussi bien au niveau du style que du 'design' du code. Et c'est encore plus prononcé avec l'arrivée du fonctionnel dans les langages objet 'traditionnels'. Entre un dev qui colle des lambda partout, un autre qui fait du code golf et un autre qui ne c'est pas mis à jour c'est parfois compliqué de trouvé le bon degré de ce qui est acceptable ou non.

    Les outils de qualité de code et d'analyse statique ont le gros avantage d'être neutre et de pas trop froisser les egos, au moins pour la partie mise en page et respect de règles élémentaires:
    méthode de 600 lignes, 12 paramètres avec 3 for imbriqués et des switch --> lol no. C'est plus simple quand c'est un robot qui le dit !

    Au niveau des IDE, il y a aussi cette analyse en temps réel qui permet d'éviter pas mal de problème en détectant des erreurs avant même la compilation. Des erreurs aussi bien de bugs potentiels que de design foireux.

    A moins d'être un compilateur vivant, c'est quand même un énorme plus (je sais qu'il existe pas mal de compilateur vivant, mais c'est loin d'être la majorité !) que les éditeurs de texte amélioré ne peuvent pas proposer.
    Non, c'est pas subjectif.

    Genre le code existant est tout indenté à 4 espaces et les accolades sur une nouvelle ligne, et les mecs arrivent et rajoutent un bout avec des tabs et des accolades sur la même ligne, juste parce qu'il n'ont pas pris 2min pour regarder le reste et s'adapter en fonction.

    Ca c'est la base, ensuite t'as exactement la même chose avec le nommage ou le style de code en général. Du code qui a des "goto error" partout pour gérer les cas d'erreur c'est pas un problème en soi du moment que c'est uniforme, si c'est de cette manière que les erreurs sont gérées dans le projet ou l'entreprise. Le mec qui arrive et rajoute un "return -1" au milieu parce que c'est son style perso et que "ça va bien, y'a rien de plus à faire en cas d'erreur" devrait être sanctionné pour ça.

    Peu importe le style, l'important c'est l'uniformité.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  12. #732
    Citation Envoyé par Orhin Voir le message
    Ouais effectivement dans ce cas c'est compliqué à mettre en place (surtout si t'as plein d'archi à supporter).
    Après tu peux toujours avoir des machines cibles de base sur lesquelles les tests de non régression sont lancés à chaque commit.
    Sachant que pour le coup vous avez une base de test très facile à obtenir avec tous les thésards qui utilisent déjà le soft (alors que généralement les bases de test c'est bien casse-couille à produire).
    Certes, on fait un peu de ça à la main mais ça reste fondamentalement non automatisable, notamment pour interpréter les résultats. Les joies du calcul en virgule flottante, faut avoir de l'expertise pour savoir si des valeurs qui sont 1000* plus élevées après avoir modifié le code est un gros foirage ou du négligeable.
    Citation Envoyé par Sidus Preclarum Voir le message
    Ben du caramel pas sucré alors...
    "Avant, j'étais dyslexique, masi aujorudh'ui je vasi meiux."

  13. #733
    Citation Envoyé par rOut Voir le message
    Non, c'est pas subjectif.
    Personnellement la syntaxe m'exaspère quand ce n'est pas celle dont j'ai l'habitude (comme les dev historiques C# qui font du Java et utilisent les conventions C# ...) mais les outils de formatage auto rendent tout ça bien secondaire...
    D'ailleurs avec un IDE bien réglé ce genre de détails ne cause plus de problème tout est formaté avant de 'commiter' le tout suivant le format adopté par l'équipe.

    Par contre une fois que sortis du formatage on rentre quand même beaucoup dans le subjectif...
    Toute la partie métrique (taille du code max, nombre de paramètres max, ...) , quelles features du langages sont autorisées ou non...

    Dans pas mal de cas des pratiques sont plus ou moins autorisées pour des raisons historiques et souvent pas bien logiques. Généralement des trucs non maîtrisés par l'équipe qui préfère interdire que comprendre.
    Généralement on trouve avec ce genre de comportement idiot un IDE imposé avec les réglages commités dans le projet et que tout le monde est censé suivre...

    J'ai vu plusieurs fois ce genre de truc, et je n'ai jamais réussis à suivre ce genre de pratiques 'imposées'

  14. #734
    Citation Envoyé par Lazyjoe Voir le message
    Certes, on fait un peu de ça à la main mais ça reste fondamentalement non automatisable, notamment pour interpréter les résultats. Les joies du calcul en virgule flottante, faut avoir de l'expertise pour savoir si des valeurs qui sont 1000* plus élevées après avoir modifié le code est un gros foirage ou du négligeable.
    Ah oui effectivement là c'est difficilement automatisable.
    Après, tu peux ne pas tout tester mais uniquement les fonctions/modules dont les résultats sont prédictibles et stables.
    C'est la faute à Arteis

  15. #735
    un poil off topic mais c'est tellement lol que je peux pas me retenir http://www.securityweek.com/microsof...ue-instability
    "Nobody exists on purpose. Nobody belongs anywhere. We're all going to die. Come watch TV." - Morty Smith

  16. #736
    Citation Envoyé par rOut Voir le message
    Non, c'est pas subjectif.

    Genre le code existant est tout indenté à 4 espaces et les accolades sur une nouvelle ligne, et les mecs arrivent et rajoutent un bout avec des tabs et des accolades sur la même ligne, juste parce qu'il n'ont pas pris 2min pour regarder le reste et s'adapter en fonction.

    Ca c'est la base, ensuite t'as exactement la même chose avec le nommage ou le style de code en général. Du code qui a des "goto error" partout pour gérer les cas d'erreur c'est pas un problème en soi du moment que c'est uniforme, si c'est de cette manière que les erreurs sont gérées dans le projet ou l'entreprise. Le mec qui arrive et rajoute un "return -1" au milieu parce que c'est son style perso et que "ça va bien, y'a rien de plus à faire en cas d'erreur" devrait être sanctionné pour ça.

    Peu importe le style, l'important c'est l'uniformité.
    rOut, tu sors de ma tête maintenant. Je bosse moi pendant que tu postes.
    Voilà, le monsieur traduit mes pensées parfaitement.

  17. #737
    Citation Envoyé par TiNitro Voir le message
    rOut, tu sors de ma tête maintenant. Je bosse moi pendant que tu postes.
    Voilà, le monsieur traduit mes pensées parfaitement.
    Oui enfin le mec rajoute des "," sur le dernier membre d'une initialisation de struct en C++03 et il donne des leçons.
    Ce comportement est inqualifiable. Et mériterait une punition par la bière.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  18. #738
    L'uniformité au risque de garder des mauvaises habitudes sur des années voir des décennies ???

    Finalement le code C de mon vieux projet est très uniforme... mais est-ce qu'il est 'bon' au regard des standards actuels ?

    @rOut, avec ta vision on ne bouge jamais d'un pouce, parce qu'historiquement un choix a été pris il y a 15 ou 20 ans ?

    Est-ce qu'il faut tout changer d'un coup pour améliorer un logiciel (ce qui n'aura jamais lieu sur un programme qui tourne et qui demanderait des années de travail avec de gros risques de régression) ?

    Perso je préfère maintenir du code qui évolue vers quelque chose de positif quitte à avoir un peu de couche 'archéologique' à l'intérieur que d'avoir un truc figé dans le marbre avec des dogmes pour seul justification...

  19. #739
    Non mais les migrations c'est une chose. Et on peut accepter d'avoir des points intermédiaires non consistants pour améliorer un aspect.
    Mais elles ne sont rendues que plus difficiles par un point de départ non uniforme.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  20. #740
    Voilà. Si migration il doit y avoir, elle se fait une fois que tout le monde est d'accord (forcé ou non) et avec tout le monde qui tire dans la même direction. Si chacun tire de son coté en rajoutant son style perso trop cool qu'il a l'habitude d'utiliser on va nulle part.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  21. #741
    Citation Envoyé par William Vaurien Voir le message
    J'ai vu plusieurs fois ce genre de truc, et je n'ai jamais réussis à suivre ce genre de pratiques 'imposées'
    Ben franchement c'est un manque de flexibilité que je trouve assez gonflant à force.

    C'est un peu comme si tu arrivais chez quelqu'un et que tu décides de ne pas retirer tes chaussures parce que chez toi tu ne les enlèves pas, alors que tu vois bien que tout les autres le font.
    Si en plus de ça c'est clairement marqué à l'entrée, c'est un gros manque de respect envers les autres.
    Ca ne veut pas dire qu'enlever ses chaussures c'est mieux ou moins bien que de ne pas les enlever, c'est juste que c'est la règle locale et que t'es pas tout seul, donc tu t'adaptes.

    Si tu fais un peu de contributions dans l'open-source, je connais très peu de projets qui vont accepter des patchs qui ne respectent pas les conventions du projet. Et souvent on te dira de remettre en forme le truc avant même de parler du fond.

    - - - Mise à jour - - -

    Citation Envoyé par William Vaurien Voir le message
    L'uniformité au risque de garder des mauvaises habitudes sur des années voir des décennies ???

    Finalement le code C de mon vieux projet est très uniforme... mais est-ce qu'il est 'bon' au regard des standards actuels ?

    @rOut, avec ta vision on ne bouge jamais d'un pouce, parce qu'historiquement un choix a été pris il y a 15 ou 20 ans ?

    Est-ce qu'il faut tout changer d'un coup pour améliorer un logiciel (ce qui n'aura jamais lieu sur un programme qui tourne et qui demanderait des années de travail avec de gros risques de régression) ?

    Perso je préfère maintenir du code qui évolue vers quelque chose de positif quitte à avoir un peu de couche 'archéologique' à l'intérieur que d'avoir un truc figé dans le marbre avec des dogmes pour seul justification...
    Tu peux faire ça petit à petit, fichier par fichier par exemple. Ou vraiment au pire fonction par fonction. Mais si c'est pour laisser tomber au milieu et te retrouver avec un truc bâtard qui a subit 35 migrations partielles, ça va être la mort à relire donc c'est AMHA pire que de garder le style old-school.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  22. #742
    On peut prendre plein d'exemples dans l'autre sens aussi: si tu arrives pour faire plombier et que les autres ne coupent pas l'eau avant d'intervenir, peut être que tu peux ne pas faire pareil, ou bien le mécano qui ne met pas de protection sur le volant avec ses mains graisseuses, ou le boucher qui ne se lave pas les mains après avoir été pisser, le dentiste qui n’anesthésie pas et qui a une fraise de 1932...

    La contribution open-source c'est un peu différent, à mon avis, pour plein de critères, ne serais-ce que si les conventions ne te vont pas ou que les manies des autres contributeurs t'insupportent, tu peux aller voir ailleurs ou même forker
    Pas en entreprise ! Et encore une fois je ne parle pas du format du code: je m'en tape. J'utilise le format fourni par l'équipe pour remettre en forme avant de committer.

    Je parle bien des choix techniques.

    Je comprend tes arguments et ils sont très bons et rationnels, après il faut parfois bousculer un peu les choses pour changer les habitudes. Et par expérience les 2 manières ont aussi bien des défauts et des qualités et sont plus ou moins appropriés suivant les circonstances.

    Après ce qui est étonnant c'est le discours d'un côté sur les mauvaises habitudes des dev (genre mes vieux collègues) qui ont l'air insupportables et inexcusables (il faudrait les changer); et de l'autre l'inflexibilité sur le code qui est sanctuarisé jusque dans ses aberrations.

    J'ai eu la chance de travailler auparavant dans des équipes ou la technique évoluait vite, ou empiler quelques couches techniques ne dérangeait pas grand monde. Et revenir dans une équipe très statique est un peu frustrant.

    Maintenir un petit bout de l'application avec de mauvais choix est finalement moins contraignant et moins risqué que de devoir faire une migration pharaonique tous les 10/15 ans.
    Et en contrepartie l'expérimentation aura sûrement permis de dégager un bon compromis.
    Et cette capacité d'adaptation est bénéfique aussi bien au code qui se voit doter de tests unitaires pour éviter les régressions et aux devs qui doivent se tenir à jour, et pas se contenter de Java 1.1 qu'ils ont appris en 98.

    Je ne dis pas que c'est meilleurs, ni qu'il faut changer de framework toutes les 3 semaines, mais être capable de faire bouger une application est finalement, à mon avis, également une force.

    Par curiosité vous travaillez avec quels langages et dans quels domaines ?
    Dernière modification par William Vaurien ; 29/01/2018 à 22h45.

  23. #743
    Citation Envoyé par William Vaurien Voir le message
    On peut prendre plein d'exemples dans l'autre sens aussi: si tu arrives pour faire plombier et que les autres ne coupent pas l'eau avant d'intervenir, peut être que tu peux ne pas faire pareil, ou bien le mécano qui ne met pas de protection sur le volant avec ses mains graisseuses, ou le boucher qui ne se lave pas les mains après avoir été pisser, le dentiste qui n’anesthésie pas et qui a une fraise de 1932...
    Et dans ces cas là, tu ne penses pas qu'il faut tout bloquer et imposer la migration ?

    - - - Mise à jour - - -

    Citation Envoyé par William Vaurien Voir le message
    Par curiosité vous travaillez avec quels langages et dans quels domaines ?
    Embarqué/jeu vidéo en ce qui me concerne, et je code en JIRA et en Confluence ^^
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  24. #744
    J'ai tendance à penser que vous êtes de gros intégristes, mais pour le coup je suis d'accord avec rOut.

  25. #745
    rOut est un gros intégriste et il a raison.

    Citation Envoyé par Tramb Voir le message
    je code en JIRA et en Confluence ^^
    J'aimerais qu'on soit plus nombreux à en faire chez nous

  26. #746
    Citation Envoyé par Tramb Voir le message
    Et dans ces cas là, tu ne penses pas qu'il faut tout bloquer et imposer la migration ?
    Ba oui évidemment. Sauf que certaines migrations sont tellement lourdes qu'elles n'arrivent jamais. Donc dans ce cas pourquoi faire perdurer une vieille tradition plutôt que progressivement remplacer les pièces défectueuses ?

    - - - Mise à jour - - -

    Citation Envoyé par Sahnvour Voir le message
    rOut est un gros intégriste et il a raison.



    J'aimerais qu'on soit plus nombreux à en faire chez nous
    Deviens chef de projet

  27. #747
    Citation Envoyé par William Vaurien Voir le message
    Ba oui évidemment. Sauf que certaines migrations sont tellement lourdes qu'elles n'arrivent jamais. Donc dans ce cas pourquoi faire perdurer une vieille tradition plutôt que progressivement remplacer les pièces défectueuses ?
    rOut ne parlait pas de défauts mais de conventions de codes et de styles, ça n'a rien à voir. Personne ne défend l'uniformité des mauvaises pratiques !
    On ne va pas dire "ah non ici on ne bound checke pas nos tableaux".
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  28. #748
    Citation Envoyé par William Vaurien Voir le message
    Ba oui évidemment. Sauf que certaines migrations sont tellement lourdes qu'elles n'arrivent jamais. Donc dans ce cas pourquoi faire perdurer une vieille tradition plutôt que progressivement remplacer les pièces défectueuses ?
    C'est pas ce que dit mon cerveau rOut.
    Il dit qu'il faut que tout le monde se mette d'accord et après on peut y aller progressivement.
    Quand chacun y met sa sauce sans concertation ça devient un putain de dawa pire que tout.

    Sérieux, si on te dit camelCase pour les variables , mais putain pourquoi tu discutes ?

    En fait, il faudrait réussir à faire comprendre que ce n'est pas une activité d'autiste solitaire, la programerie, mais un sport d'équipe.

  29. #749
    Citation Envoyé par TiNitro Voir le message
    En fait, il faudrait réussir à faire comprendre que ce n'est pas une activité d'autiste solitaire, la programerie, mais un sport d'équipe.
    Ahah le naze, on dit pas pas programerie.
    On dit programmerie avec deux m !

    - - - Mise à jour - - -

    Citation Envoyé par TiNitro Voir le message
    En fait, il faudrait réussir à faire comprendre que ce n'est pas une activité d'autiste solitaire, la programerie, mais un sport d'équipe.
    Tellement vrai. Et pas un truc de rock star egotiste.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  30. #750
    Citation Envoyé par Tramb Voir le message
    Ahah le naze, on dit pas pas programerie.
    On dit programmerie avec deux m !
    Holly shit.
    Je corrige pas du coup. On va dire que mon post est immutable.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •