Skip to content

Conversation

Wassim24
Copy link

@Wassim24 Wassim24 commented Nov 20, 2021

Hello !

Très bon test technique, assez agréable à faire, je me suis mis en condition de projet réel, et non pas purement de test. Sinon c'est plus facile de montrer tous ses muscles haha

Voici mon retour sur ce dernier :)

On remarque deux typologies de médocs principales:

  1. Celle qui se dégrade
  2. Celle qui se bonifie

Partant de ce principe il était déjà plus facile de réfactorer le code, et de le comprendre.

Dan celle qui se bonifie, on a celles qui n'expirent pas, les magic pills, cas particulier :) Toujours dans cette catégorie, la bonification est différente selon le médoc.

Dans la dégradation, on a deux cas, une dégradation à un rythme X et l'autre au double.

On pourrait imager des classes de bases, dont hériterait les autres pour définir leur comportement par exemple, dans le cas de l'exercice, cela ne me paraissait pas essentiel. Le cas du Fervex étant assez particulier, nous pousserait à complexifier le modèle.

J'avais néanmoins, un petite question.
Dans le cas des médocs expirés, on refait un tour sur tous les autres. Ce qui fait qu'un médoc "nomral" devant baisser de X chaque jours, base de 2*X après expiration.
Est-ce un comportement voulu ? J'ai gardé le même principe pour le Dafalgan, mais je préfère poser la question :)

Quelques notes et réflexions que j'ai pu avoir au cours du test:

  • J'ai pris le partis de ne pas passer sur du Typescript, car en situation de projet "réel"cela serait plus ou moins risqué.
  • Aussi, je n'ai pas voulu utiliser de patrons de conceptions tel que le visiteur par exemple.
  • Garder les changements simples, et intuitifs. Principe du KISS.
  • Ne pas anticiper les changements, évolutions, le "ça pourrait servir" ou encore "faut que ça soit le plus générique possible". - Le fait de n'avoir qu'a rajouter le Dafalgan a renforcé les deux prises de position du dessus.
  • Appliquer le principe de la SOC du DRY et un peu de SR :P
  • Garder le même output, sans devoir faire du mapping ou de transfo.
  • Faire en sorte que la PR soit assez simple à lire.

L'avantage de tout cela est de garder une base de code simple et compréhensible, notamment par des débutants (Futur stagiaire, alternant ou autres..).
Selon les besoins, on pourrait la faire évoluer vers des conceptions et des patterns plus chiadés.

Voilà grosso modo mon approche pour cette exo :)
J'ai mis à peu près deux heures pour tout faire.

Bien à vous, et bonne lecture

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant