Problème d'ogranisation

Par eloyasGithub, il y a 11 ans

Bonjour, bonjour, :)

Je souhaiterais recolté l'avis de plusieurs personnes sur un problème récurent et casse couille chez moi : Mon oragnisation.

Je suis développeur back-end bénévolle pour des projets qui m'interesse. Niveau délais, il est rare que l'on m'en impose un, cependant, c'est assez chiant de mettre 1 mois (par exemple) pour un truc qui m'aurais pris 2 semaines.

Problème

Je vais prendre l'exemple d'un projet que je réalise actuellement un site pour une esthéticienne à son compte.

Avant de commencer à bosser, je prend note du cahier des charges. Une fois le cahier des charges établi, je fais mon petit 'plan' :

Je commence à développer et là, les premiers problèmes arrivent très vite. Malgré une architecture qui me plait (sur le papier), je déplace sans arrêt mes dossiers/classe pour une sois-disant meilleur organisation (3/4 du temps, je reviens à l'état d'origine car ça ne me plait pas)... Donc je perd du temps (ben oui, on déplace un dossier, on a 4 fichiers et 1 dossiers qui contient des fichiers dedans, on ne change pas les namespaces... >.<) et comme je reviens à l'état d'origine, je re-perd du temps... Bref la galère.

Il en est de même lorsque que je fais une classe, je me demande toujours : est-ce une classe mère qui seras hérité ou est-ce l'unique classe ? A cette question, je fais tout le temps la même chose, je pars sur une classe unique, puis je change d'avis et je créer une classe fille qui seras quasiment vide, puis, je repars sur une classe unique... Encore une perte de temps non négligeable.

Des fois, j'ai tellement un bordel monstre dans mes dossiers que je refais un dossier et que je trie tout les fichiers pour les réorganiser et là, je perds énormement de temps.

Malgré cela, je suis dans les temps lorsque j'ai un délai (je prévois toujours 2 à 3 semaines de plus que mon estimation pour pallier ce problème qui me gave).

Votre avis

Voici ce que j'aimerais avoir dans vos réponses. :)

N'hésiter pas à argumenter vos réponses. :)

D'avance merci à tous ceux qui y participeront.

Cordialement.

PS : Même pour écrire ce post, j'ai eu des problèmes, j'ai ajouté des choses, supprimé d'autre choses, il n'y a qu'au travail ou je n'ai pas de problème d'organisation alors que je ne cherche pas à m'organiser. >.<

5 réponses

Alexandre #lbac, il y a 11 ans

Déjà tout dépend comment tu développes. Avec un framework ce genre de soucis n'est techniquement pas possible (à moins de rentrer dans des cas particuliers, mais pour ton exemple je ne pense pas) ;)

Si tu développes tout de ta main, le plus simple serait que tu te fasses une base saine de codà réutiliser, ton petit framework en quelque sorte gérant plusieurs éléments comme la DB, les sessions, les cookies, les formulaires et etc.

Pour être organisé il est aussi conseillé de suivre une architecture MVC (c'est peut être le cas mais tu n'en parles pas dans ton message) en rajoutant un dossier libs pour les classes et helpers pour les fonctions par exemple.

Dis nous en plus sur ta façon de développer ça pourra aider je pense ;)

eloyasGithub, il y a 11 ans

Je n'utilise pas le modèle MVC.

Qu'entends tu pars : ma façon de codé ? Que veux tu ? :)

Cordialement.

Yumi, il y a 11 ans

Je pense qu'il est impératif de se coller des normes applicable à tous les projets.

EnEn effet plus de problème d'organisation des fichier vu que c'est toujours identique. De plus, tu gagnerai du temps également lorsque tu reprendrai ton code en sachant ou chercher directement.

Bien entendu cette norme passe tant par l'architecture que pour le nomage ainsi que l'écriture de tes classes autant que tu peux sur une structure identique à la composition de celles si. Nom des variables nom des méthodes nom des class...

eloyasGithub, il y a 11 ans

Je suis déjà mes propres conventions de nomage. Mais comment cela ce fait t'il qu'au bout d'un moment j'ai l'impression que ma classe c'est le bordel ?

Yumi, il y a 11 ans

Soit ta convention est mauvaise, soit tu ne l'applique pas partout. Soit c'est juste une impression.