[Test de développement] FizzBuzz, le test de la mort

[SorenS]

Lors de ma toute première approche, j'ai fait un code fonctionnel. Mais à peine je l'avais fini, et juste avant de le montrer j'ai commencé à me poser des questions (réduire le nombre de condition par exemple).
Au final, je l'ai montré comme ça

[Mycroft]

Un peu dans le même genre, on m'a posé à un entretien d'embauche récemment :

Imaginons que je vous donne à développer ou intégrer une fonctionnalité dans un code existant absolument horrible. Mal construit, fonctions énormes, etc.

Qu'est-ce que vous faites ?

[Anthor]

Un peu dans le même genre, on m'a posé à un entretien d'embauche récemment :

Imaginons que je vous donne à développer ou intégrer une fonctionnalité dans un code existant absolument horrible. Mal construit, fonctions énormes, etc.

Qu'est-ce que vous faites ?

Ça dépend du temps accordé

[Sephi-Chan]

C'est un peu triste mais je crois que la solution est de s'adapter au code existant. Rien de pire qu'un code qui n'est pas homogène. Faire du refactoring lourd impliquerai de le faire partout, et donc de perdre un temps fou (et l'argent qui va avec… Si on regarde du côté patron).


Sephi-Chan

[Anthor]

C'est un peu triste mais je crois que la solution est de s'adapter au code existant. Rien de pire qu'un code qui n'est pas homogène. Faire du refactoring lourd impliquerai de le faire partout, et donc de perdre un temps fou (et l'argent qui va avec… Si on regarde du côté patron).


Sephi-Chan

Hélas oui.

[Ter Rowan]

bah pas forcément tu peux y aller par itération. une application, c'est plusieurs "modules/pages/classes/ ..." on peut déjà refactorer le module/classe/page qui est à modifier

en réduisant ainsi la complexité, petit à petit, on y perd pas beaucoup. Le tout est de ne pas tout cassé sans en comprendre complétement le sens sous prétexte que c'est moche, sinon on s'expose a de belles régressions

[Plume]

Il y a des applications où sans un réel remodelage y aller par itération ne mène à grand chose de plus. C'est triste mais pourtant ;(

[Cartman34]

http://fizzbuzz.pastebin.com/M9P6CmGe

J'aime bien ma 3ème version car avec echo, ça ne fonctionne pas et si on enlève les parenthèses autours des print(), ça affiche 1 (évaluation de 'Fizz'&&b=1 qui renvoie 1) alors que le print() encadre bien la chaine de caractères en tant que paramètre et $b=1 en est exclue.

[Mycroft]

De façon général, dans un environnement professionnel, il faut garder en mémoire que le code sera écrit une fois, (ou quelques fois) mais par contre lu des dizaines, (voir centaines de fois), par des gens totalement différents.

Donc le but, c'est pas de le faire le plus compact et même le plus optimisé, mais c'est de faire en sorte que le code écrit soit maintenable.

Pour être caricatural, si vous écrivez un code super optimisé, mais qu'il y a que vous qui le comprenez, c'est un peu inutile pour l'entreprise...

Donc il vaut mieux écrire un code le plus "basique" possible, avec des noms de variables les plus explicites.

C'est aussi vrai pour soit même quand on relit un code un an plus tard, mais c'est un peu moins critique parce qu'en général on comprend ce qu'on a écrit.

[Ter Rowan]

tout pareil que Mycroft