Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 275 sur 309 PremièrePremière ... 175225265267268269270271272273274275276277278279280281282283285 ... DernièreDernière
Affichage des résultats 8 221 à 8 250 sur 9247
  1. #8221
    https://jallard-super-memoryo.netlify.app/

    C'est ce que j'ai fait pour leur test technique (React + Redux).

  2. #8222
    Citation Envoyé par Captain_Cowkill Voir le message
    Petite MàJ sur ma reconversion pro : on m'a proposé un CDI \o/
    Dév front React.
    Féloches !
    Tu sais sur quel type de projet tu vas bosser ? (si c'est pas indiscret).

    Hésite pas si t'as quelques questions.

  3. #8223
    Capitàn :

    « Sans puissance, la maîtrise n'est rien »

  4. #8224

  5. #8225
    Merci les gars

    - - - Mise à jour - - -

    Citation Envoyé par Orhin Voir le message
    Féloches !
    Tu sais sur quel type de projet tu vas bosser ? (si c'est pas indiscret).

    Hésite pas si t'as quelques questions.
    Non, ils ont pas trop détaillé le projet, je pense qu'on va en parler par la suite.
    J'aurai pu leur poser la question, mais j'en avais déjà tellement

  6. #8226
    Bravo Cowkill, tu roxxes !

    De mon côté, j'ai enfin reçu mon invitation à GitHub Colpilot. C'est marrant. Et j'ai désormais de grands espoirs pour qu'il m'économise des recherches de regex

  7. #8227
    Yeah, GG !

    ---

    Tiens, je trouve ça rigolo cette tendance à ne pas être à l'aise avec les regex.
    Autant lire une regex existante je comprends que ça soit parfois compliqué, voir un enfer, tant le langage est riche (tu peux donc faire des trucs bien tordus ou difficiles à lire) et peut différer selon les normes (haaaa java vs php/perl vs js...). Mais créer une regex, vous ne trouvez pas ça amusant ? On a des outils pour nous aider en plus.
    Je dis ça, mes collègues aussi pleurent du sang quand ils apprennent qu'ils vont faire une regex

  8. #8228
    Bien joué CowKill, t'es pas passé par la piscine finalement?

    Les regex c'est quand même un langage à part, donc si tu ne le connais pas, ça te fait pas mal de doc à consulter. Je pense que les regex se prête bien aux tests unitaires cela dit, hein? Il y a des gens qui n'aiment pas non plus les tests unitaires?

  9. #8229
    Quand je fais des regex, je les encadres maintenant d'une armée de tests unitaires... car c'est facile de les écrires, mais les relire-modifier 6 mois plus tard par contre...

  10. #8230
    Et éventuellement, si tu te sens bon seigneur ce jour là, pourquoi pas écrire une ligne de commentaire Si un nom de variable court ne suffit pas.

    Je ne sais pas pour vous, mais en Java ma bible c'est la javadoc https://docs.oracle.com/javase/8/doc...x/Pattern.html, section Summary of regular-expression constructs. C'tout, c'est amplement suffisant.
    Et pour tester, soit dans IntelliJ (il reconnaît la présence d'une regex et propose un testeur), soit https://regex101.com.

    Et oui, les tests c'est juste... la base, non ? Je sais que les devs JS sont un peu arriérés avec leurs outils tout pétés, mais tout de même, ils tendent à se civiliser petit à petit.

  11. #8231
    Oui c'est la base, mais tu peux aussi les tester en contexte (tu teste la méthode/fonction qui en utilise une) aujourd'hui je test QUE la regex, donc je déporte la/les regex dans une classe/struct à part et je teste tout en isolation.

    Sinon pour les commentaires, je fais parti de l'école qui essaye de les limiter au max et de plutôt améliorer mes noms de méthodes/fonctions (une méthode = une responsabilité, si c'est plus je refactorise et je renomme) ce qui fait que si je commentais/javadoc (on a la même chose en .NET) ça reviendrai à avoir le nom de la fonction réécrit au dessus (donc pénible à maintenir et inutile).

    Le seul moment où je commente c'est pour donner des infos hors code : l'URL de la ressource utilisée, de la théorie, prévenir d'un truc contre-intuitif, etc.

  12. #8232
    Pareil que Dross pour les commentaires, je les utilise en dernier recours.

    Pour une regex, je peux éventuellement faciliter la lecture en découpant les parties alternatives (séparées les "|") ou les groupes de capture et les stocker dans des variables avec des noms qui représentent ce que la regex doit capturer, puis les concaténer pour avoir la regex finale.

  13. #8233
    Code:
    /**
     * Trim a string
     *
     * @param str the string to trim
     * @return string the trimmed string
     */
    public trim(str: string): string
    Je serais perdu sans les commentaires !! Le pire c'est que je suis déjà tombé sur plusieurs lead devs qui forçaient à écrire ce genre de commentaires partout.

  14. #8234
    Citation Envoyé par Awake Voir le message
    Code:
    /**
     * Trim a string
     *
     * @param str the string to trim
     * @return string the trimmed string
     */
    public trim(str: string): string
    Je serais perdu sans les commentaires !! Le pire c'est que je suis déjà tombé sur plusieurs lead devs qui forçaient à écrire ce genre de commentaires partout.
    Quelle horreur...

    - - - Mise à jour - - -

    Citation Envoyé par raaaahman Voir le message
    Bien joué CowKill, t'es pas passé par la piscine finalement?
    Ouaip. J'ai buté tous les concu... camarades.

  15. #8235
    Citation Envoyé par Dross Voir le message
    Oui c'est la base, mais tu peux aussi les tester en contexte (tu teste la méthode/fonction qui en utilise une) aujourd'hui je test QUE la regex, donc je déporte la/les regex dans une classe/struct à part et je teste tout en isolation.

    Sinon pour les commentaires, je fais parti de l'école qui essaye de les limiter au max et de plutôt améliorer mes noms de méthodes/fonctions (une méthode = une responsabilité, si c'est plus je refactorise et je renomme) ce qui fait que si je commentais/javadoc (on a la même chose en .NET) ça reviendrai à avoir le nom de la fonction réécrit au dessus (donc pénible à maintenir et inutile).

    Le seul moment où je commente c'est pour donner des infos hors code : l'URL de la ressource utilisée, de la théorie, prévenir d'un truc contre-intuitif, etc.
    Tests as documentation

    Effectivement responsabilité limitée, principes SOLID tout ça tout ça.

    - - - Mise à jour - - -

    En ce moment je suis avec le code produit par mes collègues...

  16. #8236
    Et tu reviens 6 mois plus tard sur ton code, ou bien un collègue peu expérimenté doit consulter ton code, et là c'est la misère. Le nom de la méthode te semblait bien sur le coup, mais finalement...
    L'exemple de Trim plus haut oui c'est totalement débile (comme exiger un % de couverture de code sans expliquer le rôle de ladite couverture), mais je pense plutôt à des fonctions liées au code métier. Une méthode calculAidesFoyerFiscal qui est sensée se baser sur plein de paramètres et une matrice, hum, bah ça vaut bien un bloc de commentaires non pas pour expliquer l'algo, mais pour permettre plus tard de vérifier l'algo si tu penses qu'il y a un soucis : le fonctionnement et la doc doivent se vérifier mutuellement. Si tu ne sais pas ce qu'est sensé faire le code, tu ne peux pas dire s'il y a un bug.
    Une solution c'est de découper le code en fonctions dont le nom est explicite, mais y'a des limites. Et de bons commentaires te feront gagner du temps si tu dois découvrir ou maintenir une base de code. Y'a rien de pire que d'arriver sur un projet et on te dit "y'a pas de doc, le code est suffisant". Ca se fait hein, mais quelle perte de temps...
    Ca n'empêche pas d'avoir une doc externe, par ex sur Confluence ou un wiki, mais hum, souvent ça passe à la trappe.
    Dernière modification par gros_bidule ; 29/05/2022 à 19h16.

  17. #8237
    Bah discuter des noms et renommer ça doit bien faire parti de la moitié de mes interactions avec les collègues quand je relis du code ; ça me parait au contraire une bonne chose de se questionner et d'améliorer la sémantique.
    (et après un certain temps, certains concepts tiennent la route et ne sont plus modifiés, ils deviennent canonique quelque-part)

    Franchement avec le temps je ne comprends pas la façon dont on a de présenter le code comme des maths ou affilié aux maths en école : à part une toute petite partie du métier, on est bien d'avantage affilié aux langues, on transforme des specs mal ficelées en langage compréhensible des machines : nous sommes des traducteurs. A partir de là, tout s'articule autour des mots à utiliser, de la manière de nommer, etc. Les commentaires, c'est des notes de bas de page, c'est pas inutile mais si t'en a sur chaque phrase faut te poser des questions.

    Pour la documentation du code métier, je préfère des tests unitaires bien nommés qui m'expliquent quels cas sont testés (et donc supportés) si mon bug/cas étrange en fait parti, je regarde le test en question, sinon, je le rajoute et je m'assure qu'il ne passe pas avant de corriger. La doc (si jamais elle existerai) je ne la regarderai même pas car rien ne m'assure qu'elle est à jour par rapport au code et les tests.

  18. #8238
    Citation Envoyé par gros_bidule Voir le message
    Et tu reviens 6 mois plus tard sur ton code, ou bien un collègue peu expérimenté doit consulter ton code, et là c'est la misère. Le nom de la méthode te semblait bien sur le coup, mais finalement...
    L'exemple de Trim plus haut oui c'est totalement débile (comme exiger un % de couverture de code sans expliquer le rôle de ladite couverture), mais je pense plutôt à des fonctions liées au code métier. Une méthode calculAidesFoyerFiscal qui est sensée se baser sur plein de paramètres et une matrice, hum, bah ça vaut bien un bloc de commentaires non pas pour expliquer l'algo, mais pour permettre plus tard de vérifier l'algo si tu penses qu'il y a un soucis : le fonctionnement et la doc doivent se vérifier mutuellement. Si tu ne sais pas ce qu'est sensé faire le code, tu ne peux pas dire s'il y a un bug.
    Une solution c'est de découper le code en fonctions dont le nom est explicite, mais y'a des limites. Et de bons commentaires te feront gagner du temps si tu dois découvrir ou maintenir une base de code. Y'a rien de pire que d'arriver sur un projet et on te dit "y'a pas de doc, le code est suffisant". Ca se fait hein, mais quelle perte de temps...
    Ca n'empêche pas d'avoir une doc externe, par ex sur Confluence ou un wiki, mais hum, souvent ça passe à la trappe.
    Ah mais je trollais sur le test as doc Mais, une variable/méthode/fonction bien nommée, c'est 50% du travail, et il vaut mieux des noms réfléchis qu'un commentaire en mousse. Mais je suis d'accord avec toi que l'écriture de commentaires est aussi importante, j'ajouterai même que c'est un minimum de documenter tout ce qui est publique. (Genre API)
    Citation Envoyé par Snakeshit Voir le message
    Mais comme on me l'a appris dans la Marine, plus les choses sont automatisées, moins ça consomme de cases plus vous en avez de libre pour choses utiles, comme penser à des filles dénudées .

  19. #8239
    Je suis d'accord à la fois avec gros_bidule et Dross...

    Je préfère me passer d'écrire des commentaires si possible car je suis très flemmard... et je préfère avoir du code autodocumenté (et je suis nul pour écrire des bons commentaires aussi).
    D'ailleurs j'écris souvent le comportement de la méthode sous forme de petits commentaires que je remplace par du code, si ce code est un peu compliqué, je transforme ça en méthode/fonction avec un nom "approprié".
    De la même manière je consulte en premier le code plutôt que la doc quand j'utilise une lib externe. Mais c'est pas toujours bien clair et je suis content de trouver de la doc qui explique le comportement en détail.

    Pour illustration la javadoc du trim, celle d'Awake étant petit joueur :

    Returns a string whose value is this string, with any leading and trailing whitespace removed.
    If this String object represents an empty character sequence, or the first and last characters of character sequence represented by this String object both have codes greater than '\u0020' (the space character), then a reference to this String object is returned.
    Otherwise, if there is no character with a code greater than '\u0020' in the string, then a String object representing an empty string is returned.
    Otherwise, let k be the index of the first character in the string whose code is greater than '\u0020', and let m be the index of the last character in the string whose code is greater than '\u0020'. A String object is returned, representing the substring of this string that begins with the character at index k and ends with the character at index m-that is, the result of this.substring(k, m + 1).
    This method may be used to trim whitespace (as defined above) from the beginning and end of a string.
    Returns:
    A string whose value is this string, with any leading and trailing white space removed, or this string if it has no leading or trailing white space.
    Alors c'est verbeux, je ne l'avais jamais lu, mais il y a des détails d'implémentation qui peuvent être important.
    Ce genre de commentaire m'a déjà bien rendu service pour d'autres méthodes du même genre (méthodes utilitaires d'apparence basique) par exemple pour la gestion des null (récement pour equalsIgnoreCase)

    Mais je me retrouve souvent dans la situation ou le nom approprié devient opaque avec le temps pour moi ou mes collègues, ou alors de nouvelles versions de la méthode arrivent avec des variations et les noms peuvent devenir ambigus...
    et le code qui était limpide devient obscure lui aussi et entraîne un cortège de question allant de "pourquoi j'ai fait comme ça déjà ?" à "mais qui est l'andouille qui à écrit ce code de merde ! Ha c'est moi ! quel quel con !"

    Ni les tests, ni la doc externe ne résolve ce problème, les premiers n'étant pas toujours simple à lire/comprendre (surtout si le métier est tarabiscoté) et la deuxième ayant une fâcheuse tendance à moisir dans un coin de wiki...

    Par contre écrire de vrai bon commentaires à la fois clairs et succints est un art difficile: trouver les mots justes pour expliquer une décision technique, un algo ou une ruse technique n'est pas si simple. Et ça prend du temps.

    Quand je relis certains de mes commentaires je comprends encore moins le code et je me demande si ça vaut vraiment la peine...

    Et bravo à toi Captain_Cowkill, tu as bien assuré, je te souhaite de trouver un projet et une équipe bien sympa pour continuer à coder sans déprimer

  20. #8240
    Citation Envoyé par Dross Voir le message
    Franchement avec le temps je ne comprends pas la façon dont on a de présenter le code comme des maths ou affilié aux maths en école : à part une toute petite partie du métier, on est bien d'avantage affilié aux langues, on transforme des specs mal ficelées en langage compréhensible des machines : nous sommes des traducteurs. A partir de là, tout s'articule autour des mots à utiliser, de la manière de nommer, etc. Les commentaires, c'est des notes de bas de page, c'est pas inutile mais si t'en a sur chaque phrase faut te poser des questions.
    C'est intéressant, et je suis d'accord que le dev n'a rien à voir avec les maths traditionnels. En revanche de mon point de vu, une très grosse partie du boulot. est de simplifier un problème. On a un "problème" très complexe, comme "comment faire un tableau de résultat triable ?", et il faut arriver à le decouper en toutes petites fonctions très simples, qui une fois assemblées sont la solution. Il y a donc un très grosse part de logique, mais à voir si elle est plus proche de la logique mathématique (une preuve par exemple) ou de la logique linguistique (comment les mots s'assemblent pour donner du sens).

  21. #8241
    Ça dépend quand même beaucoup du domaine. Dans l'informatique 'de gestion' c'est beaucoup de modélisation de processus. C'est en effet assez souvent un travail de 'traduction'.
    Maintenant il y a des applications qui demande un certain niveau en maths, et là on s'éloigne très fort du dev qui découpe de l'éléphant en tranches...
    Après j'ai l'impression qu' aujourd'hui une part très minoritaire des besoins réels demande des maths. Et des matheux ne seront d'ailleurs pas forcément meilleurs en dev que d'autres moins doués pour les maths. Dev qui emploie aujourd'hui à tour de bras (souvenir d'un jeune docteur en physique nucléaire qui s'était retrouvé à faire des workflows pour des procédures administratives et qui a eu des difficultés à comprendre ce qu'il faisait... )

  22. #8242
    On a un coté ingénierie en effet, mais je la rapprocherai d'avantage de la conception mécanique que des maths de ce coté là (un de mes diplômes est justement un diplôme d'ing en conception mécanique) : quand je conçois un moteur multi-thread, ma vision systémique qui décompose les problèmes en modules faits de plusieurs composants se parlant entre eux par des interfaces qui me viens de la mécanique m'aide infiniment plus que les mathématiques de math-sup et math-spé.

    Après des maths j'en fais aussi, mais c'est tellement anecdotique en comparaison. Dans le cadre de mon boulot on manipules des espaces vectoriels de degré n avec n ∈ ℕ. Mais même là, si j'en fais plus d'une semaine par an (max ! y'a des années où j'en ai pas fait de l'année) c'est déjà bien. Et c'est pas critique à mon métier, c'est juste un aspect domaine que j'aurai très bien pus ne jamais connaître avant et me former sur place sur l'essentiel nécessaire (inutile de dire que toute la théorie des Espace Préhilbertien de prépa était largement overkill pour l'utilisation que j'en fait actuellement, alors que je suis dev dans des produits de recherche/innovation qui utilisent ce sujet !!).

    Et de l'autre, quand tu ouvre un bouquin sur le DDD, comme celui d'Eric Evans, tu te retrouve à lire des développements importants sur des trucs critiques pour le bon développement de ton produit comme l'ubiquitous language. Vla le coté matheux du truc.

  23. #8243
    Citation Envoyé par Awake Voir le message
    Il y a donc un très grosse part de logique, mais à voir si elle est plus proche de la logique mathématique (une preuve par exemple) ou de la logique linguistique (comment les mots s'assemblent pour donner du sens).
    Les deux mon capitaine. Logique mathématique pour faire fonctionner le bouzin (l'incrémentation, les fonctions, l'algorithmique, l'algèbre de Boole, etc. sont des concepts mathématiques), logique linguistique pour se rappeler / expliquer aux collègues comment le bouzin fonctionne. Logique linguistique qui est soit appliqué directement au code soit écrite dans des commentaires, ce qui semble être une guerre des clochers qui déchaîne les passions! Perso je suis de l'école Dave Thomas / "Oncle Bob". Qui sont les prêcheurs de la chappelle d'en face?

    Pour en revenir au dev web, je suis à la recherche d'une librairie Js (préférablement TS) pour émuler un terminal, supposé tourner dans le front, et qui soit adaptable à React (ou directement écrit en React). Les commandes exécutées seront un langage créé pour l'occasion, donc j'ai besoin de pouvoir le paramétrer facilement. Le jQuery Terminalsemble être adapté à mon besoin, mais avoir à combiner les modifications du DOM virtuel par React et DOM "réel" par jQuery ne m'enchante guère. Vous utiliseriez quoi?

  24. #8244
    Selon les neurosciences, d'une manière générale, l'aptitude mentale la plus sollicitée dans le développement - et aussi dans les mathématiques - est le raisonnement spatial. Après viennent les capacités linguistiques.

  25. #8245
    Après je suis persuadé que l'enseignement de l'informatique avec un filtre par les maths est finalement assez débile aujourd'hui. Ca avait peut être du sens au temps des pionniers, mais maintenant il devrait y avoir une branche math et info pours les besoins très spécifiques et une branche moins scientifique pour les 90% restant...

    Je me suis bricolé un parcours de ce genre car j'étais très moyen en Maths, en passant par l'IUT et une fac plutôt orienté pratique que théorique. En faisant un parcours plus classique je me serais sûrement rétamé. Et au final je fais le même job que des ingés passés par prépa/école d'ingé... avec vraiment pas beaucoup de Maths.

    Mais pour la fac c'était un coup de bol, c'est en discutant avec un transfuge d'une autre fac, puis en changeant d'université pour ma derniére année que je me suis rendu compte que sous le même intitulé la mayonnaise était bien différente en fonction des lieux.
    C'était il y a plus de vingt ans, c'est peut être différent aujourd'hui, mais ça n'a pas l'air d'avoir tant changé en regardant les cursus actuel et pré-requis pour y rentrer.

  26. #8246
    De mon côté j'ai arrêté l'école en seconde, et j'ai appris à dev en autodidacte. Du coup j'ai fait beaucoup d'erreurs de dev junior pendant longtemps, et j'en fais sûrement toujours à cause d'un manque d'éducation théorique.

    Et si mon incapacité à faire des maths est très peu handicapante, mais quand je dois en faire, ben c'est très difficile. En ce moment je fais du dev sur un moteur 2d, je peux passer des après midi à essayer de résoudre des problèmes que qqun avec un bagage mathématique trouverais immédiatement.



    Citation Envoyé par GrandFather Voir le message
    Selon les neurosciences, d'une manière générale, l'aptitude mentale la plus sollicitée dans le développement - et aussi dans les mathématiques - est le raisonnement spatial. Après viennent les capacités linguistiques.
    De ce que je comprends, le raisonnement spacial ce n'est pas que se représenter mentalement qqchose, c'est aussi transformer et comprendre les liens entre des données. Donc ce n'est pas étonnant

  27. #8247
    Quand on parle de mathématiques, il n'y a pas que les polynômes du second degré et la trigonométrie qui en font partie, les problèmes du type "Toto a huit billes et trois amis avec qui il souhaite les partager...", que l'on résolvait en cours élémentaire, ont beau être... élémentaires, ça n'en reste pas moins des maths.

    Et pour mon terminal, z'avez des idées?

  28. #8248
    Je pense que nous sommes à peu près d'accord pour dire qu'un baggage de maths niveau primaire/collège est quand même nécessaire. C'est plutôt pour la suite que c'est divergent et complexe...

    et aucune d'idée pour ton terminal en js

  29. #8249
    Hors champ d'application particulier, je pense qu'il y a quand même quelques disciplines mathématiques qui sont, sinon indispensables, au moins très précieuses pour tous les développeurs :

    • Logique booléenne
    • Analyse combinatoire (dénombrement)
    • Complexité des algorithmes

  30. #8250
    Citation Envoyé par GrandFather Voir le message
    • Complexité des algorithmes
    Je vois sans arrêt des gens se pavaner sur leur code qui est O(log N) sur SO, mais en 20 ans de dev web, je n'ai jamais eu besoin de calculer la complexité d'un algo.

Page 275 sur 309 PremièrePremière ... 175225265267268269270271272273274275276277278279280281282283285 ... DernièreDernière

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
  •