Bonsoir amis développeurs

J'aimerais faire un petit audit pour connaître les méthodes de travail de chacun, histoire de débattre et d'échanger nos idées.

Ma question est : quelles sont vos méthodes de modélisation, conception, lorsque vous développez un site web ou une application web ? Des diagrammes ? De quel type ? Papier-crayon ? Logiciels spécialisés (si oui lesquels) ?

Pour ma part je fais ça assez grossièrement souvent, sur papier, avec des petits dessins pour hiérarchiser mes pages et des listes de fonctions à implémenter. Cela dit je compte me lancer dans des projets un peu plus ambitieux cet été et je vais me mettre un peu à l'auto-discipline lol

J'ai vu quelques types d'analyse fonctionnelle industrielles au lycée ces dernières années mais elles me semblent peu pertinentes pour du développement web, je cherche autre chose

Je dirais que la méthodologie pour développer une application web dynamique de quelque taille que ce soit doit suivre une chronologie simple, avec plus ou moins de détail selon l'envergure du projet bien entendu :

1. Définition du cahier des charges : description détaillée de ce qu'on veut obtenir, charte graphique, spécifications fonctionnelles : plus ce sera précis et détaillé, plus le développement sera rapide et clair;
2. maquettage : préparation de toutes les maquettes visuelles + validation;
3. Définition d'un dictionnaire de données et modélisation de la base de données : cette étape est très importante et il ne faut pas hésiter à y passer tout le temps nécessaire : une fois le développement proprement dit lancé, la moindre modification dans la base peut avoir des impacts plus ou moins graves en terme de travail à modifier/recommencer;
4. Développement du back-office (complet);
5. Développement du front-office;
6. Mise en ligne et débuggage.

Pour les outils, papier crayon au départ, et sinon pour la modélisation de bases de données, il existe des outils comme DBDesigner ou encore MySQL WorkBench dontj'espère voir un jour arriver une version finale qui fonctionne. Si tu as des moyens, il y a Power AMC qui est excellent pour faire ça aussi.

Voilà, c'est le schéma sommaire que personnellement je préconise. D'autre parleront éventuellement aussi d'UML pour la modélisation plus globale de l'application, mais je suis moins qualifié pour en parler.

Bonjour

Il ne faut pas négliger un facteur important : est-ce un travail ou en groupe ?
Je n'arrive pas à travailler convenablement en groupe, et c'est là mon gros défaut. Je ne peux donc pas de conseiller à ce sujet.

Si tu travailles seul, la solution de Cyrano est recommandée. J'y apporterais toutefois une petite modification. Je fais d'abord le front-end, puis le back-end. Je programme mes outils dans cette logique là. Mais je ne sais pas si c'est mieux ou moins bien.

En ce qui concerne UML, pour d'énorme projet, ça peut être intéressant, mais sinon c'est juste une perte de temps à mon goût. UML est très puissant, il faut s'en rendre compte. Utiliser UML pour créer un site Web simple (ce qui écarte les boutiques, les sites communautaires et les sites multi-portails), c'est comme donner de la confiture aux cochons ou utiliser un bazooka pour tuer une mouche dans un bocal ; tu l'auras compris : c'est inutile

Tu as dis :

Pour ma part je fais ça assez grossièrement souvent, sur papier, avec des petits dessins pour hiérarchiser mes pages et des listes de fonctions à implémenter.

Ce que je fais systématiquement, c'est que je programme déjà le noyau du site. I.e. la gestion des fichiers et des pages, avec les constantes, et la gestion de la bibliothèque objets.
Ensuite je développe module par modules, en utilisant ma bibliothèque (non-)personnelle.
J'utilise le papier et le crayon en guise de « todo » (à faire). Mes pensées, mes idées, mes trucs et mes machins à réaliser dans un future proche.

Lorsque je travaille, j'ai toujours tout dans la tête. Si j'ai besoin de modéliser, je me fais une liste, ou un gribouilli sur une feuille, et ça me suffit. Mais j'ai des amis programmeurs qui ont besoin de visualiser la chose, donc un diagramme s'impose. Personnellement, je pense que c'est surtout utile pour une documentation, dans ce cas, ça prend tout son sens. Sinon quand tu programmes, tu dois tout avoir en tête, et donc ne devrais pas avoir de problème

Chacun sa façon de travailler, mais si tu n'as pas vraiment de méthode, utilises celle proposée par Cyrano

Bonne chance dans ton projet Tu nous tiens au jus ?

Pour l'instant je met en place les outils (classes) qui me serviront cet été. Je vous tiens au courant

Pour l'instant je met en place les outils (classes) qui me serviront cet été. Je vous tiens au courant

Ça veut dire que tu en es à l'étape 4 ou 5 du plan de Cyrano, et que tu as donc zappé les 3 premières étapes. C'est déjà mal barré

... J'y apporterais toutefois une petite modification. Je fais d'abord le front-end, puis le back-end....

Je trouve que le faire dans ce sens n'est pas logique : on utilisera le back-office pour ajouter/modifier/supprimer des données dans la base, le front étant là pour afficher ces mêmes données. Si tu commences avec le front, ta base est vide : tu peux toujours enregistrer des valeurs en dur pour avoir un affichage convenable, mais ce n'est pas optimal, le travail ser plus long et pars garanti. Commencer par le back te permet en outre de valider ton modèle de données et la cohérence de la répartition des données en plus de te permettre de créer un jeu d'essai cohérent pour les besoins... du front

Je travaille actuellement sur un projet assez conséquent et il serait inenvisageable d'ajouter des données à la main dans la base vu sa structure et sa taille : je dois donc passer par le back office pour les ajouter et avoir un affichage normal sur le front. Comme le back n'est pas fini, je me heurte à quelques irritants. Alors je bataille pas trop longtemps, mon chef de projet a décidé qu'on bossait comme ça, ce n'est donc plus mon problème et je m'arrange avec ça, mais crois moi, travailler sur le front sans avoir un back opérationnel, c'est une erreur technique majeure.

Pour l'instant je met en place les outils (classes) qui me serviront cet été. Je vous tiens au courant

Ça veut dire que tu en es à l'étape 4 ou 5 du plan de Cyrano, et que tu as donc zappé les 3 premières étapes. C'est déjà mal barré

Non car pour l'instant je n'ai pas les modalités du projet, pour l'instant je me contente de classes génériques qui me serviront peu importe le type de site à faire.

@Cyrano :
pas bête, j'avais pas vu les choses sous cet angle. En fait quand je programme un module, je rentre effectivement des données à la main dans la db et sa table lors de leur création.
Une raison qui me force à le faire dans cet ordre, c'est aussi la flemme de faire un back hehe J'aime pas faire ça, même si c'est essentiel.
Mais je reconnais que tes arguments sont plus pertinents, pourquoi ne pas changer après tout ?

Bonne journée à tous.

Disons que c'est une discipline à adopter. Dans la mesure en plus où cette partie est pour toi rébarbative, tu as d'autant plus intérêt à la terminer en premier et tu te gardes le meilleur pour la fin.

... mais crois moi, travailler sur le front sans avoir un back opérationnel, c'est une erreur technique majeure.

un grand +1

Sans parler d'UML, je pense qu'il faille parler des tests unitaires et des tests d'intégration histoire que la reprise du code soit "gérable" au cas ou...

Bonjour,
Pour les projets j'utilise un framework mvc qui me permet (force) à suivre une certaine logique.
Le workflow est toujours le même:

• 1. Construire les contrôleurs de page.
  2. Construire les vues (squelettes html)
  3. Construire des actions de modèle si ils ne sont pas présent pour résoudre un certaine problème
  4. Construire un module entier pour résoudre des demandes complexes d'un client

Les classes sont documentées (phpDocumentor)

Armand

Bonjour

Pour mes projets, j'utilise toujours le même Kanri Gamen (Outils d'administration)
modifié par mes soins mais basé sur dataMiner - Data Administration http://www.devtwo.com/projects/

C'est vieux mais j'en ai fait un truc béton et je déploie une interface d'admin avec DB en une journée.
Fais 1 an que je joue dans le code, à force.

1. Papiers/crayon
2. Je fais ma DB sur phpmyadmin (marre que MysqlQueryBrowser me lâche tous le temps)
3. Déploiement du Kanri Gamen.
4. Le système en lui même basé sur un moteur de templetage TinyButStrong.

J'ai testé le MVC, mais j'en ai chier et comme dans mon boulot, la rapidité de dev est le maitre mot,
je fais toujours la même chose.
J'ai juste mis l'accent sur les répertoires :

bin (fichiers php)
css (les css)
inc (includes de prog du site spécifiquement)
img (a votre avis ?)
tpl (template en html exclusivement)
maintenance (kanri gamen)
-conf (fichiers de conf)
-cron (en cas de tache automatique)
-css (css de la maintenance)
-img
-inc (pour tous les projets)
-lang(Pour traduire le kanri gamen)
-lib (mes classes DataMiner)
-tpl (templates du kanri gamen)


Base de données en EUC-JP
Système d'admin en EUC-JP
Site web en SJIS.
Et j'attends mon chèque.

Heu... c'est quoi tes abbréviations là à la fin ?

Apparament programmer en MVC est assez la mode en ce moment, j'ai essayé de lire quelques tutoriels à ce sujet mais je n'ai absolument rien compris. Si vous avez des liens vers des tutoriels particulièrement bien faits avec exemples à la clef n'hésitez pas.

Apparament programmer en MVC est assez la mode en ce moment, j'ai essayé de lire quelques tutoriels à ce sujet mais je n'ai absolument rien compris. Si vous avez des liens vers des tutoriels particulièrement bien faits avec exemples à la clef n'hésitez pas.

Il y a quelques frameworks en php qui tous suivent leurs propre logique.

http://fr.wikipedia.org/wiki/Symfony
http://fr.wikipedia.org/wiki/CakePHP

Vous y trouvez des tutoriels.

http://www.open-publisher.net
Ce projet est maintenu par moi même. C'est un cms qui est basé sur le principe mvc.