Bonjour,

Je voudrais réaliser une application php/mysql, j'ai beaucoup d'informations, j'ai lu beaucoup de chôse et je ne sais pas si mon raisonnement est bon.

Mon projet, une application multi-langue, avec gestion de droits (utilisateurs/groupes), basé sur des templates (possibilités de "refaire" la partie visible par thème). Le tout en utilisant les méthodes d'urlrewriting, md5, etc...

J'ai déjà réalisé des petit projet et j'ai donc plusieurs fonctions déjà faites, pour tester un numéro de téléphone, pour un nom, etc...

Je connais la méthode merise donc j'ai commencé sur papier à faire un mcd, en parallèle j'ai déjà commencé à écrire mon code (grosse erreur du gars trop pressé). ca devient fouillis et "bordélique".

Je ne suis pas développeur, j'ai déjà entendu parler des frameworks mais pas utilisé et je ne suis pas certains que ce genre d'usine à gaz soit faites pour moi (?).

Par ou commencer et quelles sont les étapes clés pour commencer mon projet ?

Merci pour votre avis.

En ce qui concerne les frameworks, si tu veux t'en tenir à ta propre méthodologie de développement de code, autant ne pas utiliser de framework.

Quant au commencement du projet, puisque tu parles de templates, tu peux déjà partir sur la conception du code HTML final qui sera généré par ton code, de façon à bien concevoir la structure côté client, selon les différents cas de figure possibles. À ce stade, il n'est pas nécessaire d'employer des CSS, ou alors des feuilles de style minimalistes permettant de concevoir la gestion de thèmes multiples.

Quant à la méthode qui consiste à gribouiller du papier, c'est une bonne méthode pour bien visualiser ce qu'on veut faire.

Cyrano pourra t'en dire davantage.

en réalité j'aimerais bien faire (pour une fois) un truc propre (du début à la fin) et que quand je reviens sur mon code un an après je me dise pas Pffiou! je comprend rien alors que c'est moi qu'a fait ! et ce malgré les tartines de commentaires. En général quand je commence je sais à peu près à quoi je veux arriver coté utilisateur (navigateur) mais quand je m'y met je suis toujours entrain de bidouiller à droite à gauche ce qui rend les modifications extrêmement pénible et perieuse voir aléatoire.

J'ai lu de nouveau article sur les templates et j'ai l'impression que (je me trompe peux être) que c'est surtout une façon de fonctionner et de "coller" au modèle MVC.

Je suis plus très sur d'en avoir vraiment besoin, que les visiteur puisse changer l'interface visuelle complète de l'application ne me semble pas obligatoire.

En revanche le modèle MVC me plait bien, après bien sur faut le respecter, en gros c'est la dessus que je pars presque à chaque fois et un an après je "pond" une requête SQL sur la page d'index avec une * alors qu'il me faut juste deux, trois informations.

J'ai lu cet article : adopter-un-style-de-programmation-clair-avec-le-modele-mvc

je ne sais pas si c'est une référence mais peux être une piste pour moi ?

En fait si je commence admettons par créer une page index.php (exemple) avec le contenu visuel (figé) de ce que je veux au final et qu'ensuite j'intègre les notions de authentification/permissions/changement de langue, etc... serait un bon commencement ?

Merci.

Hey ,

pourquoi est-ce que tu associes les frameworks à des usine à gaz ? C'est justement le contraire. Un framework respecte des règles, normes et conventions claires et précises. On met toujours en avant la réutilisabilité du code, chose très pratique.

Ça rejoint donc ce que je voulais te dire. Avant de démarrer un projet, il faut commencer par créer ses outils. Soit ces outils proviennent d'un framework, proviennent de divers sites, ou sont fait maisons. Peu importe, il faut avoir un ensemble d'outils qui se comprennent et qui soient homogènes, c'est à dire cohérent.

Une fois cet ensemble d'outil, tu vas pouvoir commencer à bâtir ton application. Attention à toujours utiliser des scripts le plus générique possible afin de pouvoir les réutiliser. C'est de cette façon que ton projet va pouvoir évoluer.

Ensuite, partir sur un MVC est une très bonne idée. Reste à trouver le MVC qui te convient, ou qui te plaît surtout. Car la majorité des MVC sont corrects (on peut après parler de performances ou de services proposés) mais il faut avant tout que tu le maîtrises et que tu sois familier avec afin de produire le meilleur résultat possible. Il faut donc bien étudier toutes les solutions qui te sont proposées.

ou alors il y a la methode hakazizi qui consiste a se lancer tete baisser et a foncer droit devant sans prendre aucune note et quasiment sans commenter ses scripts peut-etre sur un mur ou peut-etre sur la voie du succès mais a ce stade qui peut le dire...
je debute encore et pourtant cela fait un an que je m'y suis mis serieusement au php.
mais avant de se lancer dans php il faut un minimum de connaissance en html.
Je code encore le html "a l'ancienne comme certain aime le dire mais je me soigne.
j'essaye tout et n'importe quoi j'adapte ce que je connait a la situation.
et j'essaye d'appronffondire mes connaissances afin d'améliorer au mieux mes scripts.
je sait ce n'est pas la meilleure facon de faire mais c'est la mienne.

Cyrano pourra t'en dire davantage.

Comment résister...

Je vais te suggérer une méthodologie générale qui sera à mon avis la plus efficace.

1. Décrire dans un document de façon sommaire ce que tu veux faire, un peu comme dans ton sujet de présentation, mais tu peux enrichir. Papier et crayon seront tes instruments les plus utiles à ce stade ou à la rigueur un traitement de texte qui te permettra de corriger, modifier ou refaire sans gaspiller de papier.
2. Maquettes : c'est un point important, crée les maquettes des pages que tu veux voir en bout de course : mets du contenu en dur dedans, c'est sans importance, tu valides l'aspect visuel et éventuellement le comportement si tu utilises du JavaScript. Et bien entendu tu valides le code avec différents navigateurs, au minimum Internet Explorer et Firefox, mais tu pourras avantageusement ajouter Opéra et un navigateur sous Linux si tu peux y accéder (ou l'inverse si tu n'es pas sous Windows, plus Safari si tu peux disposer d'un Mac. Safari sous Windows est à mon avis trop marginal, tu peux l'essayer aussi, mais je resterais prudent avec ce truc surtout si tu utilises beaucoup de JavaScript.
3. Modélisation de ta base de données : ça, c'est un point à ne surtout pas négliger : un schéma mal conçu qu'il faut modifier, ça signifie ré-écrire tout ou partie de l'application.
4. Définition de l'architecture : arborescence des répertoires/fichiers : on ne met pas tout en vrac à la racine, on répartit logiquement chaque fichier à sa place : les images, les feuilles de style, les vues, le PHP lui même réparti selon qu'il s'agit de classes métier générique ou de code autre, etc...
5. Si tu veux vraiment pousser loin, commencer à lister les tests unitaires à concevoir pour valider tes développements à venir;
6. Commencer à coder ton application...

Et comme tu vois, avant d'écrire la moindre ligne de code, tu as largement de quoi t'occuper, la première partie étant l'analyse qui ne devrait pas occuper moins de 40% de la durée du projet global.

Je sais qu'on va peut-être passer pour des vieux (wow, ça me ferait bizarre ^^, Cyrano est habitué ), mais vraiment, il faut utiliser son papier et son crayon. Plus j'avance en informatique, et moins je passe de temps devant l'ordi. Ça peut paraître vraiment bête, mais en fait, un problème clairement posé sur papier, et tu as déjà ton script décrit.

Je ne suis pas fan de modélisation et ce genre de chose. Ça, c'est dans ma tête. En revanche, je gribouille toujours, je trace 3 rectangles, 2 flèches, 3 lignes de codes par si, un tableau par là, un semblant d'algo dans un coin encore propre ... mais à la limite, la méthodologie n'est pas importante. Ce qui est important, c'est de réfléchir avant de concevoir un projet. Juste en réfléchissant, on va savoir où se trouve les problèmes et c'est plus facile de gommer que de réécrire 600 lignes de code, crois-moi.

Ensuite, si tu as fais proprement, tu pourras toujours reprendre le problème 3 ou 4 mois après, tu pourras t'y replonger sans soucis. C'est en fait ce qu'on appelle une documentation si je ne m'abuse ? Si en plus tu as fais une documentation API (c'est à dire, de bas niveau, donc les commentaires dans le code), alors là, c'est peinard. Autant toi, que des collèges, pourront reprendre le code sans problème. C'est ce qu'on appelle du bon travail .

Je ne suis pas fan de modélisation et ce genre de chose. Ça, c'est dans ma tête. En revanche, je gribouille toujours, je trace 3 rectangles, 2 flèches, 3 lignes de codes par si, un tableau par là

ça par contre ça ne fonctionne que si tu travailles tout seul, donc c'est peut-être bien aussi de voir un peu la modélisation, les langages et quelques outils qui vont avec pour le jour où tu seras amené à bosser en équipe, et où tu ne travailleras que sur une partie du projet.

... mais à la limite, la méthodologie n'est pas importante...

Pas d'accord, c'est justement ça qui est le plus important : Quelle que soit la méthodologie employée, il faut en avoir une, quitte à l'affiner avec le temps. Méthodologie, ça signifie ordre et méthode, on ne fait pas tout en vrac au gré de l'humeur du jour, sans quoi on se retrouve dans une sorte de capharnaüm indescriptible et le projet devient une usine à gaz ingérable.

Bonjour à tous, et merci pour toutes ces réponses.

Je vais te suggérer une méthodologie générale qui sera à mon avis la plus efficace.

Alors par rapport à ce schéma je suis à l'étape 2 mais trop pressé j'ai déjà voulu commencer l'étape 3 !
En ce qui concerne la partie 1 je n'ai pas fait de dossier technique comme ça pourrait se faire dans une boite de développement mais j'ai presque une demi ramette de papier que je me traine depuis 2/3 sur lesquelles y'à des schéma des interfaces visuelles (grossières) que je souhaite obtenir avec les différentes actions possibles selon les habilitations des groupes etc...

Il faut que j'adopte une méthode claire pas forcement simple (mais ça serait mieux) pour que le jour ou quelqu'un qui passerait derrière moi ne se sente pas obligé de dire : on prend les mêmes et ont recommence !

en ce qui concerne :

...une sorte de capharnaüm indescriptible et le projet devient une usine à gaz ingérable.

C'est ça ! ça je connais et je veux plus faire !


Merci pour vos réponses, je vais réflaichir encore un peu.

... mais à la limite, la méthodologie n'est pas importante...

Pas d'accord, c'est justement ça qui est le plus important : Quelle que soit la méthodologie employée, il faut en avoir une, quitte à l'affiner avec le temps. Méthodologie, ça signifie ordre et méthode, on ne fait pas tout en vrac au gré de l'humeur du jour, sans quoi on se retrouve dans une sorte de capharnaüm indescriptible et le projet devient une usine à gaz ingérable.

Je me prends. La méthodologie que tu utilises n'est pas importante, mais il faut en avoir une, oui. Elle diffère — comme l'a fait remarqué oucklileou — du nombre de personnes qui travaillent sur le projet.

Y a aussi la méthode japonaise qui consiste à travailler à plusieurs sur un projet sans méthodologie, et à trouver le coupable et lui faire payer le retard et les problèmes du projet, avant d'engager une boite externe qui vas te facturer le double pour réparer tes erreurs.

Ça marche bien car ça fait marcher l'économie.
Plus on est de fous et moins y a de riz !

Y a aussi la méthode japonaise qui consiste à travailler à plusieurs sur un projet sans méthodologie, et à trouver le coupable et lui faire payer le retard et les problèmes du projet, avant d'engager une boite externe qui vas te facturer le double pour réparer tes erreurs.

Et pour en parler, c'était toi le coupable je suppose ?

ça veut dire quoi "faire payer le coupable" ? Des Yakuzas lui coupent des doigts ?

ça veut dire quoi "faire payer le coupable" ? Des Yakuzas lui coupent des doigts ?

Tu as regardé Taxi 2 hier soir à la télé ?

Pour en revenir au sujet, la méthode décrite par Cyrano est une des meilleures, ne serait-ce que par son approche pragmatique.