Les débutants se posent souvent une question toute bête en développant : “Comment j’organise mes fichiers ?“. Mine de rien un projet de développement va générer un paquet de fichiers si on travaille correctement.
C’est souvent les petits détails qui génèrent les plus gros soucis a terme
Oui, parce que pour ceux qui suivent pas au fond, on code pas TOUT dans 1 seul fichier hein.
Alors comment on organise ses fichiers / dossiers pour que ce soit lisible par les collègues développeurs, par la communauté ou mieux : par mon moi du futur. Il est ultra aisé de passer 30~ minutes à la réouverture d’un projet pour se remettre en tête la structure, se remettre dans la logique de code, où démarre le programme etc.
Justement aujourd’hui on regarde un peu comment s’organiser efficacement.
La structure des fichiers vs l’architecture métier
Première confusion de la plupart des développeurs juniors (et même les seniors) : l’architecture métier != de la structuration des fichiers.
L’architecture métier c’est quoi frère ?
L’architecture métier c’est les acronymes des familles du genre :
- MVC
- MVVM
- VIPER (Pas mal utilisé en mobile)
- BLOC (Flutter)
- MVP
- Pour une liste assez exhaustive j’ai trouvé cet article
L’architecture des fichiers ce n’est donc pas comment vous allez organiser votre logique de code, c’est à dire tel objet doit faire appel à tel autre objet pour afficher telle vue, mais comment vos fichiers sources seront hiérarchisés, comment vos dossiers seront nommés et comment vos packages / vos namespaces vont s’appeler etc.
Du coup les fichiers
Vous avez 2 choix pour faire simple :
Par couches
.
├── Main.kt
├── models
│ ├── Action.kt
│ ├── Events.kt
│ └── User.kt
├── network
│ ├── UserApiService.kt
│ ├── ContentAdapter.kt
│ └── SocketListener.kt
└── screens
├── Homepage.kt
├── Dashboard.kt
├── EndGame.kt
├── Scores.kt
└── WaitingRoom.ktIci, on va s’organiser par couche logique du programme, souvent vous allez avoir besoin de gérer des modèles de données (vos classes en POO), des écrans (ou des vues) et un niveau d’accès réseau.
Mais j’aurai très bien pu rajouter un dossier database , un dossier controller (dans le cas d’une architecture MVC), un dossier viewModel (dans le cas d’un MVVM). Le principal à retenir est que cette organisation se veut logique par couches logiques (logique ?) de votre application.
C’est cool parce que :
- On comprend vite les différents points d’accès du programme
- Mais c’est à peu près tout.
Pas simple, mais pour les petits projets ça va aller :)
Cette organisation ne favorise pas du tout la découverte du projet (discoverability en anglais), pour un nouveau développeur ou pour votre vous du futur.
En effet, à la racine du projet vous allez vite comprendre qu’il ya du réseau et une BDD par exemple. Mais si je vous dit ”corrigez moi un bug lié à l’utilisateur”, bahhhhhhh là… c’est plus compliqué, car la logique de gestion de l’utilisateur va sûrement toucher au réseau, à la BDD, et aux vues.
Bon courage, il va falloir se balader longtemps dans le projet pour trouver comment tout communique.
Par features
Là c’est plus sympa, mais peut-être moins connu.
.
├── Main.kt
├── user
│ ├── APIService.kt
│ ├── APIConfig.kt
│ ├── LoginFragment.kt
│ ├── LoginViewModel.kt
│ ├── RegisterDialogFragment.kt
│ ├── User.kt
│ └── UserRepository.kt
├── gameplay
│ ├── GameViewModel.kt
│ ├── GameWebSocketRepository.kt
│ ├── SocketState.kt
│ ├── WebSocketHandler.kt
│ └── WiseRepository.kt
└── highscore
...Par features on va organiser par fonctionnalité du programme, dans notre exemple de jeu, on a une partie gameplay, une partie de connexion et de gestion du joueur user et une partie liée aux scores. Donc on va avoir 3 dossiers à la racine qui correspondent à nos 3 features : user, gameplay et highscore. Ensuite on peut faire des sous-dossier de features si par exemple dans ma feature user j’ai tout ce qui est gestion de profil et connexion.
C’est cool parce que :
- Cette fois on se retrouve de suite dans ce que fait notre programme !
- Mais trouver la partie Réseau, Base de données et Vue est un exercice qui va être conditionné par la bonne volonté du développeur de nommer ses fichiers correctement : Pas dingue.
Le meilleur des deux mondes : Hybridation Couche + Features
*Après moi je propose, vous faites comme vous voulez. *Mais il s’avère que cela donne de bons résultats.
Si on peut plus rien dire
Alors comment on fait cette fois ?
.
├── Main.kt
├── gameplay
│ ├── GameViewModel.kt
│ ├── GameWebSocketRepository.kt
│ ├── WiseRepository.kt
│ ├── network
│ │ ├── GameWebSocketRepository.kt
│ │ ├── SocketState.kt
│ │ ├── WebSocketHandler.kt
│ │ └── WebSocketManager.kt
│ ├── models
│ │ ├── PlayerEvent.kt
│ │ └── SpaceEvent.kt
│ └── ui
│ ├── GameOverFragment.kt
│ ├── LoopGameFragment.kt
│ ├── RoomJoinDialogFragment.kt
│ └── WaitingRoomFragment.kt
...Cette fois on organise d’abort par features, puis dans chaque features on fait des dossiers par couche.
├── feature1
│ ├── network
│ ├── models
│ ├── views
│ │ └── ...
│ └── storage
│ ├── Database.kt
│ └── Repository.kt
├── feature2
│ └── models
│ └── ...L’idée est d’avoir accès rapidement aux fonctions, puis une fois la fonctionnalité choisie quand meme pouvoir ranger les fichiers par couche d’accès (Réseau, base de données, etc.) correspondant à la fonctionnalité.
Eh beh voilàààà là c’est cool.
Personnellement c’est une organisation qui me correspond, qui s’adapte plutôt bien aux projets de petite à moyenne taille.
Je fais comment si je dois coder le prochain Excel ?
Hum, pour des projets triple A genre Excel Game of the year edition (gros jeu), on va commencer à monter son niveau de développeur.
On va commencer à standardiser les parties partagées par plusieurs fonctionnalités comme l’accès réseaux, les modèles de données et certaines vues. Et on va le faire en créant des bibliothèques permettant de simplifier la navigation dans le projet.
Vous utilisez déjà des bibliothèques (ou libraries en anglais) dans vos projets j’en suis certain. D’ailleurs il y en a des très connues, qui vont même jusqu’à vous fournir des conventions sur comment structurer vos fichiers, si si, on appelle ca des frameworks.
Les devs quand ils pensent aux frameworks
Est-ce que vous commencez à tilter l’intérêt des frameworks tout d’un coup ? Cela vous évite de réfléchir à tout un tas de conventions (nommage, organisation de fichiers, etc.), cela vous donne les briques communes à globalement tout les projets (accès au réseau, base de données, systèmes de rendu des vues, etc.).
En plus, vous pouvez facilement brancher dessus d’autres briques (les bibliothèques) pour coder le moiiiinnns posssible.
Et SURTOUT cela évite que chacun fasse sa propre sauce.
Plus d’excuse après :p