Comment organiser au mieux son code

[Air]

Salut à tous,

Mon projet commence à être conséquent et mes listes de fonctions, requêtes commencent à être longue.
Je passe parfois plusieurs minutes à chercher et retrouver.

Comment procédez-vous pour classer tout cela ?
Avez-vous une bibliothèque de vos requêtes ?

En posant ce message, je viens de penser à classer par ordre alphabétique. C'est bête mais je n'y avait pas pensé avant.

Et vous ? Vous utilisez d'autres moyens/ outils ?

[Murthy]

J'ai bien envie de te dire : CTRL + f mais je sens que ça ne répond pas vraiment (totalement) à ta question. Et c'est surtout, parce que je suis dur à la détente et que je n'ai pas bien saisi la question

[Xenos]

Salut,

perso, je n'irai surtout pas faire une "bibliothèque de requête": ça se scale très très mal ce genre de chose (= passé les 10 ou 20 pages, t'auras une biblio de 1000 requêtes abominablement ingérable, et tu ne sauras pas quelle requête est utilisé où et ce sera ingérable).

Pour ma part, tout est classé par page: chaque page (chaque URL) a un dossier correspondant dans l'arborescence des sources, qui contient les éléments de la page. Je peux donc faire Ctrl+Shift+F ("rechercher dans un dossier" sur intellij) pour trouver littéralement un élément.

Par exemple, varii.space/oc/map/viewsingle/ affiche les infos d'un oc [Objet Céleste] et correspond au dossier /sources/php/request/handler/oc/map/viewsingle/
Dans ce dossier se trouve 1 (et 1 seul) fichier PHP appelé au nom du dossier + Facade.php ("OcMapViewsingleFacade.php"). Dans ce fichier se trouve les classes nécessaires à la page (1 classe de façade OcMapViewsingleFacade par laquelle tous les appels extérieux passeront, une classe Handler correspondant au controleur, une classe ModelBean qui constitue le modèle de la page (donc, une classe avec des champs publics et 0 méthode), des classes ModelBean* [ModelBeanOc, ModelBeanOrbitships,...] qui correspondent à des sous-beans du modèle (= des bean donc des classes avec des champs publics et 0 méthode, et dont les instances sont les valeurs des champs du ModelBean), et éventuellement, une classe HtmlFormatter qui transforme le ModelBean en code HTML à renvoyer au client.
Dans ce dossier se trouvent aussi les fichiers CSS et JS (et éventuellement les images) spécifiques à la page (si c'est une page HTML qui en a besoin). Ils sont eux aussi nommés comme la facade, sans le Facade ("oc-map-viewsingle.css" "oc-map-viewsingle.js", mais je n'ai pas de règle pour les images)
Dans ce dossier se trouve enfin un fichier sql (oc_map_viewsingle.sql) qui définit une procédure stockée (oc_map_viewsingle) dont le rôle est l'aller récupérer toutes les données nécessaires à la page. Chacun des resultset retournés par la procédure est automatiquement mappé à un ModelBean*, permettant de remonter les données de la procédure à la page.

De cette manière, si je cherche un truc, je sais très souvent dans quelle page je le cherche, donc je sais dans quel dossier le cherche. Comme je sais aussi, généralement, le type de truc que je cherche (une classe CSS? une requête SQL? un code PHP?) alors je sais dans quel fichier il se trouve. Il n'y a plus qu'à aller le chercher dedans. Si je ne sais pas dans quelle page le truc se trouve, je le cherche dans tout le projet (c'est véloce chez IntelliJ, franchement bluffant; mais Netbeans ou Eclipse font sûrement pareil).

[Edit] J'ai présenté plus en avant mon archi dans un topic dédié, pour ne pas dériver celui-ci

[Mexicanoon]

Yo ! Comme Xenos j'utilise la recommandation MVC (Modèle \ Vue \ Controller).

C'est-à-dire que je sépare à chaque fois dans des fichiers distincts :

- les interactions avec la BDD (SQL, PHP dans mon cas)
- le code affiché sur le navigateur (HTML, CSS, JS...)
- le code qui traite les requêtes du client et mouline tout ce qu'il faut pour lui retourner une réponse (PHP)

Et comme j'utilise le framework Symfony, j'utilise l'arborescence de dossiers et les conventions de nommage de dossiers, fichiers et classes qu'il recommande.
En gros :
- dossier des vues (fichiers HTML dynamiques, complétés à la volée côté serveur avant d'être synthétisés et renvoyés finalisés au client)
- dossier des contrôleurs
- dossier des modèles

Ce qui sert pour le nommage des fichiers, c'est ce qui s'appelle les Entités
En gros une Entité, c'est une table dans ma BDD. Par exemple "User", "Article", "Message"...

Chaque fichier s'appellera en gros :
- UserVue.html
- UserController.php
- UserModel.php

Voilà pour le schéma d'ensemble.
Le plus important chez moi : bien compartimenter son code, avec une fonction = une tâche bien précise. Pas de doublon. Des noms descriptifs et sans ambiguité pour nommer fonctions, classes et dossiers. Voilà

[Xenos]

Je suis peut-être biaisé par le foutoir de l'archi du bureau, mais je trouve que le classement "un dossier de vues, un dossier de modèle, un dossier de controleur" est absolument immonde à l'utilisation...

99% du temps, quand on rajoute une feature dans un projet (un jeu web), on a besoin de traverses ces 3 dossiers... Je trouve ça hyper lourd: vous arrivez à faire avec vous? Si oui comment?

Perso, ayant rangé dans 1 dossier toute ce qu'il faut pour 1 page (sa vue, son controleur et son modèle, tous dans le même fichier PHP finalement même si la logique de récupération des données est dans un autre fichier [la procédure stockée]), je trouve ça vachement plus simple pour rajouter des pages ou des features: je modifies ma structure de données en BDD, je dump cette structure dans un dossier dédié (j'ai un sql/table/*.sql qui contient 1 fichier définissant chaque table, sous forme d'un CREATE TABLE), puis je crée 1 dossier pour ma page avec la nouvelle feature...

D'expérience, séparer M/V/C dans des dossiers différents (par "type"), c'est franchement lourdingue à l'usage :/


@Mexicanoon
Pourquoi as-tu 1 vue HTML pour la table "User"? t'as 1 page web / table? Perso, dans mon cas, je me doute que j'aurai 1 page de classement, 1 page de profil pour chaque joueur, et 1 page de profil du joueur connecté qu'il peut éditer, donc 3 "vues" qui utiliseraient directement la table User, et non 1 seule?

[Sephi-Chan]

J'ai pas mal bossé avec des frameworks MVC et je ne trouve pas que séparer les modèles/vues/contrôleurs dans des répertoires séparés soit un problème. Je comprends bien l'approche par page et je la trouve intéressante, mais il y a aussi des modèles assez génériques (par exemple User, Player, Game…) pour aller dans un répertoire générique.

De mon côté, je développe assez rarement avec une arborescence ouverte, je trouve mes fichiers via le fuzzy search de mon éditeur : je tape "uscon" pour trouver le contrôleur users, je tape "uso" si je veux le contrôleur du channel websocket "user socket", etc.

Il faut dire que ça fait pas mal de temps que je n'ai pas fait d'applications avec des pages : je bosse quasi exclusivement avec des SPA en React (ou plus récemment en Elm), servis par des API JSON (en Ruby ou Elixir). Du coup je raisonne plutôt en composants et chacun d'eux extrait le sous-ensemble du state (unique à l'app) dont il a besoin.

[Mexicanoon]

@Xenos
J'ai plusieurs Vues pour tout ce qui est lié à User, là c'était plus pour ilustrer mon propos.
Dans mon dossier relatif aux Vues, j'ai en fait plusieurs sous-répertoires, dont un qui s'appelle User et qui contient des fragments de page HTML en Twig (un code méga-pratique utilisé par défaut dans Symfony). Ces fragments peuvent être utilisés par mes Controllers pour être assemblés, dans le cadre d'une réponse en JSON pour faire suite à une requête AJAX, ou d'une page web HTML complète.

Ce qui est important dans l'organisation, c'est de suivre le même schéma partout. Si je commence à modifier la logique dans un dossier parce que je trouve ça plus pratique, alors je requestionne l'ensemble de l'architecture. Mais au bout d'un moment faut arrêter un choix, et s'y tenir. Y a pas de choix 100% tip top de toutes façons !

Je pense qu'il faut avant tout penser code réutilisable, code lisible, chopper une architecture et s'y tenir.
Un truc important aussi il me semble pour s'y retrouver, c'est de bien faire 1 fichier = 1 classe. Et de baptiser le fichier du même nom que la classe.
Dans chaque classe, je mets pas tout de suite mes fonctions par ordre alphabétique, je mets plutôt dans l'ordre : le __construct, les constantes, les fonctions publiques, les privées, les protected... et au sein de chaque groupe je trie par ordre alphabétique.

[Air]

Mes modèles sont multi pages . c'est à dire que les requêtes peuvent être utilisés par plusieurs page différentes. Donc l'organisation 1 page , un model n'est pas adapté dans mon cas.
Peux-être devrais-je faire un exercice de liste l'ensemble des mes requêtes et vérifier qui les appelle ?
En tout merci pour vos retours qui comme d'habitude sont toujours constructifs et argumentés.

[Xenos]

C4est vrai que garder une seule archi (une seule logique), c'est l'essentiel !

c'est de bien faire 1 fichier = 1 classe

Pas tout à fait à mon sens, car PHP n'a pas la notion de "private class" (comme Java l'a). Dans ces cas-ci, je trouve très pratique d'avoir plusieurs classes dans le même fichier: une principale (avec le même nom que le fichier) et qui est celle utilisée par tout code externe à ce fichier, et d'autres classes "privées", pas utilisées par un code externe au fichier.

Je rejoins l'idée que l'ordre alphabétique des méthodes est bidon (ok "pas forcément à suivre") car c'est chiant à faire, et surtout, pas pratique pour suivre une logique de code. Perso, je les classe comme toi Mexicanoon, à ceci près que j'ai parfois une "private" au-dessus de la "public" qui l'utilise.

Après, c'est vrai que contrairement à blinde de frameworks/archis, je n'ai quasiment pas de modèle générique en fait (puisque je tappe directement dans le SQL pour récupérer les données nécessaires à la page). Cela change un peu la donne...

PS:
Je suis content: en 1H ce matin, j'ai implémenté un Formatter Excel générique pour montrer au boulot qu'on pouvait utiliser ce genre d'archi même si on doit exporter de gros tableaux de données Ca sera peut-être utile en plus aux joueurs qui veulent se faire des fichiers Excel pour leurs stratégies...

[Zero]

Je me demande si la vraie solution 4x4 tout-terrain ne serait pas le fait de documenter, à sa propre intention, le code. Je ne parle pas de commenter le code, mais plutôt de se créer des tutos "comment faire pour modifier ceci" ou "comment faire pour ajouter cela". Tant que c'est frais, c'est facile à faire. Six mois plus tard, en suivant le tuto, on retrouve nos petits.