Skip to content
This repository has been archived by the owner on Jan 8, 2020. It is now read-only.

[ WORKER ] Refactor structure #24

Open
zteeed opened this issue Sep 25, 2019 · 0 comments
Open

[ WORKER ] Refactor structure #24

zteeed opened this issue Sep 25, 2019 · 0 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@zteeed
Copy link
Owner

zteeed commented Sep 25, 2019

--> copy/paste from #16

Je pense qu'on peut améliorer la structure du projet:
Pour l'instant il y a deux modules:

  • redis_interface: qui représente les interactions avec le monde
  • parser: qui parse

Je trouve que le module parser est super car il est totalement self-contained. Il prend des strings et les parse en structures de données que tu veux, il fait son taff et juste sont taff..

Par contre redis_interface fait un peu tout... Genre dans worker/worker/redis_interface/challenges.py, la fonction retrieve_category_info n'a aucun rapport avec Redis, et en plus elle ne fait pas l'interface avec le système et redis mais plutôt entre le système et Rootme. Alors je sais bien que c'est une fonction qui n'est utilisée que dans ce fichier (d'ailleurs les fonctions non exportées devraient être préfixées d'un _), mais ca correspond quand même pas à ce qu'on attend intuitivement d'une "interface vers redis".

Je pense que l'actuel redis_interface peut être split en 3 modules, ça va t'aider à avoir une architecture plus claire, écrire tes tests plus facilement et potentiellement de pouvoir faire des refactoring plus facilement.
redis_interface pourrait devenir:

  • redis_interface: garder le module, mais y mettre QUE des fonctions qui font l'interface entre ton système et redis. (en gros ca serait un adapter, dans le "port and adapter pattern")
  • root_me_interface: Les fonction qui concernent l'interfacage avec rootme, en gros ca serait toujours un appel au HTTP_client + parse et on retourne la valeur. (comme ca ca se teste super simplement)
  • ??? le nom reste à définir (peut être juste worker) qui établit le workflow de ton worker. Genre par exemple, quand on a un ordre d'update, d'abord on uitilise l'interface redis pour récup le timestamp, on check si la resource doit être update, si elle doit être update, on utilise l'interface rootme pour recup les infos, puis on met des données dans redis en utilisant l'interface redis. C'est un exemple de "workflow" qui serait contenu dans ce module

C'est juste une proposition, mais avec ça, juste en lisant la 3ème classe on peut comprendre ce que fait concrètement ton worker, et en lisant les interfaces, on peut comprendre COMMENT il fait

@zteeed zteeed changed the title [ WORKER ] [ WORKER ] Refactor structure Sep 25, 2019
@zteeed zteeed added enhancement New feature or request help wanted Extra attention is needed labels Sep 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant