Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 12 sur 12 PremièrePremière ... 289101112
Affichage des résultats 221 à 234 sur 234
  1. #221
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 139
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 139
    Points : 9 153
    Points
    9 153

    Par défaut

    Citation Envoyé par pmithrandir Voir le message
    en fait, ca permet malgré tout d'en filtrer certains. Sur les 50-60 candidats que j'ai vu cette année, environ 10-15 se sont vautré dessus, dont 5 qui nous avait entourloupé en entretien sur des notions de programmation.
    (.../...)
    Voilà, c'est ça que je voulais dire. C'est un test simple, et ça permet d'éliminer entre 25% et 50% des candidats(suivant le profil). Ensuite, on passe aux choses sérieuses.

    Et là, on va plus cibler. Pour recruter mon remplaçant, l'idéal serait une double rupture, pour comparer des fichiers. Parceque généralement, on fait beaucoup plus que comparer les fichiers, et un outil de comparaison standard ne permet pas de faire ce que l'on fait - mais en entretien, on a pas le temps d'aller jusqu'à une solution complète à un problème complet. D'autres métiers auront d'autres exigences.

    Mais ça ne sert à rien de sortir la grosse artillerie pour des gens qui ne savent même pas faire un fizzbuzz. D'ou son utilité.


    Sinon, j'ai fait mon Lycée en 90-93, et je n'ai jamais entendu parler de Fibonacci. Jusqu'à il y a quelques mois(en cherchant sur le net une astuce technique). Si le recruteur demande "la solution à la suite de Fobonacci", effectivement, il va recruter un matheux, pas un programmeux. Si par contre il dit "tiens, on cherche à mettre en place une fonction qui rende 1 pour 1 ou deux, et au delà additionne les deux chiffres précédents", là, il fait appel au programmeur.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  2. #222
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    Citation Envoyé par Bluedeep Voir le message
    D'où ma surprise car le lycée d'avant 1979 que j'ai connu ne devait pas être très différent du lycée d'avant 1976 dont tu parles, sauf erreur de ma part.
    ben si, justement.. Puisque justement j'étais dans l'année de test pour les maths modernes... Une seule fois... L'année d'après, c'était passé dans les programmes.. Mais moi j'ai terminé ma scolarité en maths anciennes..

    Bon, ça n'a guère d'importance, mais je trouve juste que ce genre de questions est un peu aberrante, et ne saisit pas ce que l'on attend réellement...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  3. #223
    Expert Confirmé Sénior Avatar de Marco46
    Homme Profil pro Marc
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    1 864
    Détails du profil
    Informations personnelles :
    Nom : Homme Marc
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 1 864
    Points : 4 115
    Points
    4 115

    Par défaut

    Citation Envoyé par Nasky Voir le message
    Les entretiens où faut donner la définition de "classe", "polymorphisme", etc. ne donnent aucune indication. N'importe quelle personne est capable d'apprendre ça en 5 minutes si elle ne le sait pas.
    Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.
    Tu vois sur quoi le candidat débouches, par exemple quelqu'un qui me parle de polymorphisme et qui ne me parle pas de Factory j'ai du mal. Après si le mec ne prends pas l'initiative tu enchaines de toi même sur les design pattern, tu lui en fais coder un, tu lui demandes quels sont les avantages/inconvénients de tel ou tel pattern, lesquels il connait, lesquels il a réellement utilisés, pourquoi, etc ...

    Ca permet au minimum de pouvoir détecter les imposteurs, et sinon ça te donnera son autonomie dans ton architecture et quel investissement en temps il va falloir lui consacrer.

    En revanche quelqu'un qui me dit qu'on apprend la POO en 5 minutes je le classe direct dans la catégorie des branquignols, finance ou pas.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  4. #224
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 940
    Points
    940

    Par défaut

    Citation Envoyé par Nasky Voir le message
    Par exemple, écrire un code qui calcule le N-ième élément d'une suite de Fibonacci. Si tu fais du récurssif, c'est direct out.
    Même si c'est du récursif terminal ?

  5. #225
    Membre émérite Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 940
    Points
    940

    Par défaut

    Citation Envoyé par deadalnix Voir le message
    En plus d'être impossible dans le cas de fibonacci (cette suite est doublement récursive), c'est inutile car ne change pas la complexité algoritmique.

    Cette technique permet simplement de ne pas faire de stack overflow et de gagner en performance sur les fonction récursives, rien de plus. Ce ne sont pas les problèmes posés par Fibonacci.
    Voici pourtant une fonction fibo en récursivité terminale, avec une complexité temporelle linéaire en fonction de n :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    #include <stdio.h>
    #include <stdlib.h>
    #include <assert.h>
    
    /* tail recursive */
    int fibo_aux (int u2, int u1, int i)
    {
      if (i == 0)
        return u1;
      else
        return fibo_aux (u1, u1 + u2, i - 1);
    }
    
    int fibo (int n)
    {
      assert (n >= 0);
      if (n <= 1)
        return n;
      else
        return fibo_aux (0, 1, n);
    }
    
    int main (int argc, char *argv[])
    {
      if (argc == 2)
        printf ("%d\n", fibo (atoi (argv [1])));
      else
        printf ("%d\n", fibo (20));
    
      return EXIT_SUCCESS;
    }
    Je reconnais cependant que la version itérative est bien plus simple à écrire.

  6. #226
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 686
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 686
    Points : 15 737
    Points
    15 737

    Par défaut

    Salut,
    Citation Envoyé par el_slapper Voir le message
    Et là, on va plus cibler. Pour recruter mon remplaçant, l'idéal serait une double rupture, pour comparer des fichiers. Parceque généralement, on fait beaucoup plus que comparer les fichiers, et un outil de comparaison standard ne permet pas de faire ce que l'on fait - mais en entretien, on a pas le temps d'aller jusqu'à une solution complète à un problème complet. D'autres métiers auront d'autres exigences.
    Ah, les ruptures...

    Ce n'était pas pour une comparaison de fichiers, mais pour un examen... d'algorithmie lors de mes cours.

    J'ai du en gérer 7 en cinq minutes j'avais une réponse qui aurait suffit à mon prof, mais, comme j'avais deux heures à tirer, je lui ai sorti le nassi-schneiderman complet pour le problème qu'il me posait

    Ceci dit, c'est quelque chose qui a tendance à faire fuir pas mal de gens
    Citation Envoyé par Marco46 Voir le message
    Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.
    Tu vois sur quoi le candidat débouches, par exemple quelqu'un qui me parle de polymorphisme et qui ne me parle pas de Factory j'ai du mal.
    Et encore...

    Demandes moi de te parler de polymorphisme, je te parlerai de substituabilité (sans doute de liskov), d'adaptabilité du comportement, mais la factory, je n'en parlerai sans doute pas sur ce sujet.

    Par contre, demandes moi ce que je préconise lorsqu'une classe doit utiliser un objet polymorphe, et là, tu auras droit à la factory, avec en plus un petit détour par SRP et autres ISP
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #227
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 788
    Points
    1 788

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Sinon, j'ai fait mon Lycée en 90-93, et je n'ai jamais entendu parler de Fibonacci. Jusqu'à il y a quelques mois(en cherchant sur le net une astuce technique). Si le recruteur demande "la solution à la suite de Fobonacci", effectivement, il va recruter un matheux, pas un programmeux. Si par contre il dit "tiens, on cherche à mettre en place une fonction qui rende 1 pour 1 ou deux, et au delà additionne les deux chiffres précédents", là, il fait appel au programmeur.
    On est d'accord, le but n'est pas de tester si le candidat connais ou pas fibonacci, mais s'il est capable, pour peut qu'on lui donne la formule, de pondre la fonction qui le calcule. Dans ton cas donc, c'est bien la seconde question qui a du sens, la première permettant avant tout de trouver des singes savant, et pas forcement des gens intelligents.

    Et ensuite de voir s'il se rend compte que la solution naïve à une complexité exponentielle, et s'il est capable d'en trouver une un peu plus maligne (j'ai donné la solution, c'est ~10 lignes de code avec une boucle, on ne parle donc pas ici d'un truc de haut vol) en O(n).

    Je suis quand même vraiment étonné de voir les gens ici s'étonner d'une telle question. La solution est très simple. Certains demandaient si j'avais pondu le code de mémoire, et bien absolument pas ! Je l'ai écris en live dans mon précédent post, en moins de 5 minutes.

    La solution naïve est vraiment un problème du même niveau que fizzbuzz, mais ça permet d'ouvrir sur une question de complexité algorithmique, ce qui est un moyen de transitionner dans l'interview.

  8. #228
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 788
    Points
    1 788

    Par défaut

    Citation Envoyé par I_believe_in_code Voir le message
    Voici pourtant une fonction fibo en récursivité terminale, avec une complexité temporelle linéaire en fonction de n :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    #include <stdio.h>
    #include <stdlib.h>
    #include <assert.h>
    
    /* tail recursive */
    int fibo_aux (int u2, int u1, int i)
    {
      if (i == 0)
        return u1;
      else
        return fibo_aux (u1, u1 + u2, i - 1);
    }
    
    int fibo (int n)
    {
      assert (n >= 0);
      if (n <= 1)
        return n;
      else
        return fibo_aux (0, 1, n);
    }
    
    int main (int argc, char *argv[])
    {
      if (argc == 2)
        printf ("%d\n", fibo (atoi (argv [1])));
      else
        printf ("%d\n", fibo (20));
    
      return EXIT_SUCCESS;
    }
    Je reconnais cependant que la version itérative est bien plus simple à écrire.
    Attention, je n'ai pas dit que c'était impossible (ou alors j'ai parlé trop vite) mais que ce n'était possible sur la solution récursive naïve (car doublement récursive justement). Alors que le memoize le permet (au prix d'une consommation mémoire en O(n), il n'y a pas de magie).

    Une autre chose qui m'a surpris : que l'on considère la récursivité terminal comme académique. Pourtant, c'est une optimisation très courante, que presque tous les compilateurs font (et c'est bon à savoir car ça peut changer la tête des stack traces). De plus, le fonctionnel en général est la meilleur réponse que l'on ai à l'heure actuelle pour la programmation parallèle (l'OOP est carrément mauvaise sur ce sujet). Il y a du multicore jusque dans votre téléphone maintenant, ça devient urgent de s'y mettre.

  9. #229
    Modérateur
    Avatar de gangsoleil
    Profil pro
    R&D en systemes informatiques bas niveau Unix/Linux
    Inscrit en
    mai 2004
    Messages
    8 489
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : R&D en systemes informatiques bas niveau Unix/Linux

    Informations forums :
    Inscription : mai 2004
    Messages : 8 489
    Points : 21 616
    Points
    21 616

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.
    Tu vois sur quoi le candidat débouches, par exemple quelqu'un qui me parle de polymorphisme et qui ne me parle pas de Factory j'ai du mal. Après si le mec ne prends pas l'initiative tu enchaines de toi même sur les design pattern, tu lui en fais coder un, tu lui demandes quels sont les avantages/inconvénients de tel ou tel pattern, lesquels il connait, lesquels il a réellement utilisés, pourquoi, etc ...
    Plus que de voir si le candidat sait placer des mots-clefs, je pense qu'il faut lui demander quelle est la bonne utilisation. Par exemple, quelle est la bonne longueur pour une classe, ou bien combien de niveaux d'heritages sont raisonnables dans un projet.

    Le soucis pour le recruteur, c'est qu'il n'existe pas de reponse toute faite, et que donc ca demande de reflechir, de pousser le candidat pour savoir ce qu'il a vraiment compris de ces concepts.

    Exemple de mauvaise reponse, que j'ai vue en entretien : L'heritage ? Pas plus de 40 niveaux, et ca roule.
    Modérateur "C", "Informatique Générale & Hardware" et "Unix"
    Les règles du forum

  10. #230
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 686
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 686
    Points : 15 737
    Points
    15 737

    Par défaut

    Citation Envoyé par Freem Voir le message
    La ou les propos me choque, cela dis, c'est quand il dit que le gars à écris la javadoc AVANT le code... comment donc qu'il a fait, il est tellement fort que sa conception est pile poil le résultat final? Nan parce que, chez moi, la conception dégrossis pas mal, c'est vrai, mais elle évolue au fur et a mesure que le code progresse.
    (bon, je sais, j'arrive deux guerres en retards )
    Hé bien, honnêtement, tu devrais essayer...

    Sincèrement, le fait d'écrire la javadoc (la documentation doxygen) au moment où tu n'en est qu'à la création de l'interface de ta classe t'oblige à concevoir clairement:
    • le but recherché par ta classe
    • La responsabilité que tu veux donner à ta classe, et donc, à veiller qu'elle reste unique
    • les pré / post conditions et les invariants de tes fonctions
    • l'utilisation qui sera faite des arguments que tu vas passer
    • les exceptions éventuellement lancées

    Cela te permet, éventuellement, de mettre le doigt sur d'autres problèmes de conception

    En plus, cela te donne à la limite "tout ce qu'il faut" pour te permettre d'au moins définir les tests unitaires qui sont à faire (quitte à ce que ce ne soit que l'algorithme de tests, si tu ne sais pas quelle bibliothèque est utilisée par la société).

    Si tu as la chance de pouvoir travailler en binôme, tu te trouves dans une situation idyllique:

    Tu "fourgue" ta classe documentée, non implémentée, à ton binome qui va écrire les tests unitaires sur base de ce qu'il lit dans la doc (que tu viens de créer), et, pendant ce temps, tu implémentes les différentes fonctions "à ton rythme".

    Si tu as bien écrit ta doc, ton binôme doit pouvoir comprendre ce que tu as écrit sans avoir à te demander quoi que ce soit, et, si tu as correctement suivi ce que tu as mis dans la doc, tous les tests unitaires devraient passer, y compris ceux qui vérifient que tu lances une exception ou les cas hors conditions

    Pour le reste, les tests unitaires, je ne sais simplement pas les faire
    Et pourtant, si tu garde des fonctions simples, correctement nommées, et qui ne font qu'une chose, c'est simple :
    1. tu testes le résultat obtenu avec deux ou trois cas "de base", qui doivent passer
    2. tu testes le résultat obtenu avec les cas "hors limites" en terme de pré/post conditon / invariant
    3. Une division se teste avec un dénominateur nul, pour voir comment cela se passe
    4. Tu rajoutes quelques cas "border line" qui pourraient te venir à l'esprit

    Refactorer le code intelligemment, en revanche, ça implique de maîtriser entièrement l'existant. En 2H, il vaut mieux ne pas avoir 10K lignes de code à lire.
    Ne t'en fais pas, tu n'auras pas 10 K lignes de code à analyser pendant ton test...

    Mais bon, tu peux très bien tomber sur une fonction de 150 lignes qui mout le café, lance la machine à laver et fait la vaisselle...

    Il est assez facile dans de telles conditons de la diviser en trois fonctions distinctes, non
    Quant aux solutions multiples, ça dépend tellement du problème que je trouve ça limite ridicule. Sinon, donnez-moi 3 solutions pour récupérer la valeur max entre 2 entiers? Bref, selon le niveau d'abstraction du problème et selon la situation, on ne peut pas nécessairement avoir tant de solutions que ça.
    Peut etre pas pour un cas aussi basique, mais si tu savais le nombre de fois où je répond à des questions sur ce forum en donnant au moins deux solutions, après avoir ré exprimé les besoins du PO car il s'attaque au problème à l'envers ou parce qu'il a manqué de précision dans sa demande... Tu serais sans doute surpris
    Et au final, je rejoins certains qui estiment que la motivation du type en face est importante. Un génie qui s'ennuye ne sera pas forcément aussi productif qu'un idiot qui se fait plaisir.
    Je ne crois pas qu'il faille forcément être un génie, mais il ne faut en tout cas certainement pas être idiot...

    Je crois d'abord et avant tout qu'il faut arriver à mettre en oeuvre la deuxième ligne de ma signature et arriver à comprendre ce que les gens demandent.

    Et on ne mesure pas la motivation par un test de code.
    Très certainement pas la motivation, ca, je te l'accorde sans le moindre problème.

    Par contre, leur capacité d'analyse et leur compétence, voire leur débrouillardise et leur capacité d'adaptation, ca, presque sans aucun doute
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  11. #231
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 819
    Points
    12 819

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.
    Pour la dernière partie, d'accord.

    Pour la première, en revanche, être compétent en OO n'en fait pas un bon programmeur/concepteur..

    Le mec qui fait 250 000 classes pour modéliser quelque chose qui se ferait simplement avec 2 ou 3 en procédural est à mon avis un mauvais concepteur...

    Mais je sais que je ne suis pas "in"...

    (comme j'ai cité ci-dessus : faire des gettr/setter pour récupérer un élément d'une structure aussi simple qu'un point est une absurdité de modélisation)
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  12. #232
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 686
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 686
    Points : 15 737
    Points
    15 737

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    (comme j'ai cité ci-dessus : faire des gettr/setter pour récupérer un élément d'une structure aussi simple qu'un point est une absurdité de modélisation)
    Faire un mutateur sur un point, très certainement...

    Faire un accesseur sur un point, cela peut encore se discuter

    Plus sérieusement : si le point représente une caractéristique de ton objet à laquelle tu dois pouvoir accéder, cela peut se comprendre (pour l'accesseur, car, pour le mutateur, le comportement idéal sera sans doute beaucoup plus proche de move (direction + distance) ou de move(position finale) .

    Par contre, de manière générale (et bien que l'on puisse trouver des exceptions, comme partout ) placer un mutateur sur une classe ayant sémantique de valeur sera très souvent une aberration de conception.

    Et, de manière encore plus générale, si A utilise B en interne et que B utilise C en interne, il serait totalement aberrant que tu doive connaitre C pour pouvoir manipuler B depuis A
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  13. #233
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 139
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 139
    Points : 9 153
    Points
    9 153

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    ben si, justement.. Puisque justement j'étais dans l'année de test pour les maths modernes... Une seule fois... L'année d'après, c'était passé dans les programmes.. Mais moi j'ai terminé ma scolarité en maths anciennes..
    (.../...)
    un peu de hors sujet, mais rigolons un peu avec les maths modernes(en anglais)
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  14. #234
    Membre Expert
    Inscrit en
    juillet 2006
    Messages
    1 537
    Détails du profil
    Informations forums :
    Inscription : juillet 2006
    Messages : 1 537
    Points : 1 788
    Points
    1 788

    Par défaut

    Citation Envoyé par souviron34 Voir le message
    Le mec qui fait 250 000 classes pour modéliser quelque chose qui se ferait simplement avec 2 ou 3 en procédural est à mon avis un mauvais concepteur...

    Mais je sais que je ne suis pas "in"...
    Non, tu es raisonné. Les design patterns ou les best practice (ou quoi que ce soit d'autre) servent à résoudre des problèmes. Si tu n'as pas le problème, les utiliser n'a pas de sens.

    Ceci dit, j'ai aussi travaillé avecd es gens qui étaient alergique au découpage, et c'est pas franchement mieux. Il y a un équilibre à trouver.

Liens sociaux

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
  •