Methode de developpement PHP

Après avoir réalisé quelques petits projets PHP sans aucune méthode de
développement, je m'apercois que cela devient de plus en plus handicapant
de ne pas suivre de véritable "gestion de projet". En effet, j'en arrive à
des fouillis de code inmaintenable.

Ta question est double..
il y a d'une part les outils et d'autre part la methodologie...

pour les outils, il existe des framework bien sympathique.
je t'invite à regarder EZPublish. (je ne l'utilise par car j'ai un truc
maison, mais c'est tres bien)
Bon evidement l'inconveniant d'un framework, c'est souvent qu'il faut au
depart apprendre à s'en servir,
et puis c'est souvent un peu contraignant, surtout quand tu as besoin de
réaliser rapidement quelque chose.

Donc c'est qu'en meme un effort qu'il faut faire que de respecter le
framework.
sinon ca sert a rien.

C'est pourquoi, je fais appel à votre expérience pour savoir "comment bien
débuter dans un projet PHP". Comment faites-vous lorsque vous avez un
cahier des charges assez imposant pour choisir par quoi débuter.
Utilisez-vous des diagramme UML et la programmation objet. Commencez-vous
par établir les prémices de la base de données (s'il y a lieu). Faut-il
tout modulariser? Gérez-vous tout de suite les aspects tels que
l'authentification ou faites-vous cela vers la fin?

Alors la.
tu trouveras un article tres interessant sur le net qui s'appelle la
cathedrale et le bazar.
l'article oppose deux methodes de developpement:
- le développement structuré : Etude suivie du developpement.
- le developpement bordelique genre je code et apres je modifie, voir je
recode certaines parties.

Et les resultats de l'etude sont plutot surprenant...
L'idée etait de comprendre comment les projet open source (souvent codé dans
le bordel) arrivent a donner un résultalt.

Peut-être que certains voudront bien me faire part de leur expérience dans
ce domaine ou me diriger vers des liens.

Pour finir... la documentation...
et la c'est le plus chelou... car souvent il faut respecter une syntaxe
imposée par l'outil de production de documentation.
Dans mon cas, j'en ai pas trouvé un qui me convienne...
Mais bon il en existe quand meme des tas...
un seul regret quant a ces outils... il n'y a pas de système d'alerte
indiquant l'absence de documentation...
Exemple:
Pour me forcer a mettre des commentaires, mes pages PHP s'analysent
(s'analysaient) elle meme avant d'etre parsées par le PHP, du coup, si je
n'ai pas mis assez de commentaires, ca me declanche une erreur...

Dans la pratique, j'ai fini par couper cette fonctionnalité un jour de
rush... Ce fut une belle erreur parce que je ne l'ai jamais remise ;)

Jérémy.

Bref...
Il faut de la discipline pour éviter que ton code ne devienne hyper
bordelique...

Etienne

Jeremy wrote:

Utilisez-vous des diagramme UML et la programmation objet.
Commencez-vous par établir les prémices de la base de données (s'il y a
lieu). Faut-il tout modulariser? Gérez-vous tout de suite les aspects
tels que l'authentification ou faites-vous cela vers la fin?

j'ai l'impression que je m'en sort pas trop mal sans UML
mais avec une conception par objet et une base de données
qui suit le modele.

Est-ce qu'il faut tout modulariser ? oui biensur qu'il
faut factoriser au maximum. Factoriser, c'est un gage
d'efficassité, mais en meme temps, tout ce qui est factorisé
doit etre parametrable, et dans certains cas, la reutilisabilité
peut etre délicate a moins que les "blocs" de codes soit
extremement petits, c'est ce que j'appelle des methodes
atomiques ; ces methodes sont courtes et ne font qu'une
seule chose et le font au mieux. Ce sont ces méthodes
qui permettent la reutilisation. Generalement les methodes
appelant les methodes atomiques sont bcp moins reutilisables.


L'idéal serait d'adopter un framework objet ou pas, ou d'en
developper un a ta convenance avec les quelques 10 ou 20 objets
indispensables. Le reste ce sera des objets metiers.

Jeremy wrote:

Bonjour,


Après avoir réalisé quelques petits projets PHP sans aucune méthode de
développement, je m'apercois que cela devient de plus en plus
handicapant de ne pas suivre de véritable "gestion de projet". En effet,
j'en arrive à des fouillis de code inmaintenable.

je connais ça !-)

C'est pourquoi, je fais appel à votre expérience pour savoir "comment
bien débuter dans un projet PHP".

Que ce soit du PHP ou non n'a pas vraiment d'influence en l'occurrence.
C'est un problème de méthodologie, pas de technologie.

Comment faites-vous lorsque vous avez
un cahier des charges assez imposant pour choisir par quoi débuter.

Je commence en général par une analyse fonctionnelle (recenser et
décrire 1/les fonctionnalités attendues *du point de vue de
l'utilisateur*, 2/ les contraintes techniques). A partir de ça, je
commence à réfléchir aux solutions techniques, j'explore quelques pistes
si nécessaires (recherche de bibliothèques ou composant existant, prise
de contact avec les technos ou API mal connues, validation de solutions
possibles etc), puis je vois comment le tout s'organise.

Pour ce qui est de l'implémentation, je commence en général par mettre
*rapidement* en place le *squelette* général, avec des implémentations
bidons des parties 'basses', puis je passe aux choses sérieuses - ce qui
entraine généralement des modifications de l'architecture générale,
parce que je suis trop bête pour penser à tout dès le début !-). Dans
cette phase, je commence de préférence par les parties les plus risquées
(technos mal connues, fonctionnalités critiques) car c'est là qu'une
erreur d'analyse ou de conception aura le plus d'impact.

Utilisez-vous des diagramme UML et la programmation objet.

Ca dépend du projet et des technos, mais dans le cadre de ta question,
en général, oui. Par contre, mes diagrammes UML sont généralement juste
des griboullis sur papier brouillon. Ils sont là pour me permettre
d'organiser mes idées, pas pour imposer une architecture figée.

En ce concerne la POO, attention à la tendance à vouloir faire du Java
en PHP, c'est généralement (!) une erreur.

Beaucoups de choses qui nécessiteraient des classes spécifiques en Java
se codent très bien en PHP/Python/Ruby/Perl/TonLangageDeScriptPréféré
avec des listes ou des hash. Bref, ce n'est pas parce que tu représente
quelque chose en tant que classe ou objet dans tes diagrammes UML que tu
doit nécessairement en faire une classe pendant l'implémentation.

Commencez-vous par établir les prémices de la base de données (s'il y a
lieu).

Ca fait partie du travail d'analyse et de conception. Avec un bon modèle
de données, le code est généralement _relativement_ simple. Bien sûr, le
schéma peut avoir besoin d'évoluer pendant l'implémentation.

Faut-il tout modulariser?

<mode='normand'>
Autant que possible, mais pas plus, et pas n'importe comment !-)
</mode>

Dans l'idéal, il faudrait faire en sorte de pouvoir modifier
l'implémentation d'un module sans modifier son interface. Dans la
pratique, on a régulièrement besoin de devoir modifier les interfaces,
parce qu'il n'est pas évident de trouver la bonne du premier coup.

Les deux écueils que je rencontre souvent sont :
- la tendance à vouloir rendre paramétrable des trucs qui n'en ont pas
besoin (en tout cas pas pour le moment),
- la tendance à rendre une API trop dépendante d'une autre.

Gérez-vous tout de suite les aspects
tels que l'authentification ou faites-vous cela vers la fin?

Ce genre d'aspect est généralement transversal, donc l'ajouter à la fin
impliquerait trop de modifications dans le code. C'est typiquement le
genre de choses dont il faut tenir compte dès le début AMHA, et parmi
les premières parties à mettre en place - pour moi, ça fait partie du
squelette.

Par contre, tu peux très bien commencer avec un module
d'authentification bidon, développer d'autres parties, puis implémenter
effectivement ce module.

D'un manière générale, cette méthode (un peu de réflexion avant,
beaucoup d'aménagements pendant) ne fonctionne correctement qu'avec un
bon gestionnaire de version et des tests unitaires aussi automatisés que
possible (ce qui n'est pas toujours évident dans le cas du développement
Web). L'idée est qu'il faut pouvoir réaménager le code sans souci de
casser quelque chose. Un bénéfice secondaire des tests unitaires est
qu'ils forcent généralement à bien modulariser le code pour le rendre
testable.

Un autre outil intéressant est un 'bug-tracker', si possible lié au
contrôleur de version. Le duo Subversion/Trac est pas mal.

Toute dernière chose, plus spécifique à PHP : bien séparer la logique
applicative de la logique de présentation. PHP est en soi un bon langage
de template, mais il est préférable d'avoir d'un côté des 'templates'
(des pages HTML avec quelques appels PHP pour substituer dynamiquement
les données à afficher - avec des conditionnelles et des boucles si
nécessaire, mais aucune modification de l'état du système) et de l'autre
la logique (du code PHP sans aucune balise HTML nulle part).

Le pattern MVC (Modèle/Vue/Controleur) est une bonne application de ce
principe : les 'vues' sont les templates, la logique est dans le modèle
(en POO, généralement des classes 'métier'), et le controleur - la page
php appelée par le client - se charge des interactions entre vues et
modèle. Dans la pratique, il arrive que modèle et controleur soient
confondus, mais ça a souvent pour effet de faire assumer au modèle des
responsabilités qui ne le concerne pas vraiment. Là, c'est à voir en
fonction de la complexité générale de l'appli et de sa finalité...

HTH
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"

[...]

Un autre outil intéressant est un 'bug-tracker', si possible lié au
contrôleur de version. Le duo Subversion/Trac est pas mal.

Toute dernière chose, plus spécifique à PHP : bien séparer la logique
applicative de la logique de présentation. PHP est en soi un bon langage
de template, mais il est préférable d'avoir d'un côté des 'templates'
(des pages HTML avec quelques appels PHP pour substituer dynamiquement
les données à afficher - avec des conditionnelles et des boucles si
nécessaire, mais aucune modification de l'état du système) et de l'autre
la logique (du code PHP sans aucune balise HTML nulle part).

HTH

Merci pour ton partage d'expérience et celui de Etienne et Marc.

Je vais m'intéresser aux différentes pistes que vous proposez. J'utilise
déjà certaines "méthodes" proposées. En particulier, la séparation du
code de la présentation grace à un système de template de base(pas
encore plongé dans smarty).

En ce qui concerne les frameworks, il est vrai que c'est assez peu
parlant pour moi. Disons que j'essai de réutiliser du code mais je fais
peu appel à des bibliothèque déjà développées par manque de connaissance
de celle-ci. Peut-être devrais-je m'intéresser à PEAR.

Quand à la documentation du code, il est vrai qu'il va falloir que je
fasse des efforts là-dessus...

--
Jérémy

[...]

Toute dernière chose, plus spécifique à PHP : bien séparer la logique
applicative de la logique de présentation. PHP est en soi un bon
langage de template, mais il est préférable d'avoir d'un côté des
'templates' (des pages HTML avec quelques appels PHP pour substituer
dynamiquement les données à afficher - avec des conditionnelles et des
boucles si nécessaire, mais aucune modification de l'état du système)
et de l'autre la logique (du code PHP sans aucune balise HTML nulle
part).

Merci pour ton partage d'expérience et celui de Etienne et Marc.

Je vais m'intéresser aux différentes pistes que vous proposez. J'utilise
déjà certaines "méthodes" proposées. En particulier, la séparation du
code de la présentation grace à un système de template de base(pas
encore plongé dans smarty).

Pourquoi faire ? PHP *est* un système de template. Enfin, à l'origine,
c'en était un, et ça continue à être utilisable comme ça. C'est con,
j'avais l'url d'un article assez intéressant de ce point de vue, mais
pas moyen de remettre la main dessus...

En ce qui concerne les frameworks, il est vrai que c'est assez peu
parlant pour moi. Disons que j'essai de réutiliser du code mais je fais
peu appel à des bibliothèque déjà développées par manque de connaissance
de celle-ci. Peut-être devrais-je m'intéresser à PEAR.

Il y a des choses intéressantes dans PEAR, mais d'une manière générale
je ne suis pas trop fan... Il y a aussi pas mal d'autres frameworks MVC,
et de toutes façons, ce n'est pas bien compliqué d'en mettre un en place.

Quand à la documentation du code, il est vrai qu'il va falloir que je
fasse des efforts là-dessus...

La meilleure doc reste le code lui-même, ce qui implique qu'il soit bien
rédigé (nommage etc). Les commentaires ne doivent servir qu'à donner une
vue d'ensemble (d'un point de vue fonctionnel), préciser ce qui n'est
pas forcément évident (choix d'implémentation, algos un peu complexes,
hypothèses de départ, cas non traités etc). Un commentaire erroné est la
pire chose qui soit, et on a vite fait de ne pas mettre à jour les
commentaires, donc...

mes 2 centimes,
Bruno

Etienne SOBOLE a dit le 08/03/2005 à 09:39:

Pour me forcer a mettre des commentaires, mes pages PHP s'analysent
(s'analysaient) elle meme avant d'etre parsées par le PHP, du coup, si je
n'ai pas mis assez de commentaires, ca me declanche une erreur...

Ça c'est une bonne idée.
Après bon c'est surtout utile dans la création d'outils.

Quand tu dois réaliser une application, la documentation n'est pas
toujours nécessaire.

loufoque wrote:

Etienne SOBOLE a dit le 08/03/2005 à 09:39:

Pour me forcer a mettre des commentaires, mes pages PHP s'analysent
(s'analysaient) elle meme avant d'etre parsées par le PHP, du coup, si
je n'ai pas mis assez de commentaires, ca me declanche une erreur...

Ça c'est une bonne idée.
Ha ??? Moi j'aimerais pas...

Après bon c'est surtout utile dans la création d'outils.

Quand tu dois réaliser une application, la documentation n'est pas
toujours nécessaire.

La documentation, si, toujours. Mais documention != commentaire. Les
commentaires dans le source ne sont qu'un élément de doc, et uniquement
destinés aux développeurs.

Enfin, bon, AMHA, d'après moi, c'est mon opinion que je partage, etc...
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"

bruno modulix a écrit/wrote :

Pour ce qui est de l'implémentation, je commence en général par mettre
*rapidement* en place le *squelette* général, avec des implémentations
bidons des parties 'basses', puis je passe aux choses sérieuses - ce
qui entraine généralement des modifications de l'architecture
générale, parce que je suis trop bête pour penser à tout dès le début
!-). Dans cette phase, je commence de préférence par les parties les
plus risquées (technos mal connues, fonctionnalités critiques) car
c'est là qu'une erreur d'analyse ou de conception aura le plus
d'impact.

On peut aussi se servir d'une simple maquette de l'application réalisée à
partir de l'analyse et de la conception. Une bonne architecture
(Fusebox/MVC) et des bibliothèques (PEAR) et le tour est joué. Ça évite de
passer par toute cette phase risquée dont tu parles... Mais en passant par
là on apprend souvent beaucoup, seulement certains y restent !

Ca dépend du projet et des technos, mais dans le cadre de ta question,
en général, oui. Par contre, mes diagrammes UML sont généralement
juste des griboullis sur papier brouillon. Ils sont là pour me
permettre d'organiser mes idées, pas pour imposer une architecture
figée.

Pour éviter les gribouillis de coin de table j'utilisais Visio de Microsoft.
Une autre solution consiste à écrire ses diagrammes UML plutôt qu'à les
modéliser. D'autres outils intéressants : DBDesigner 4 (modélisation BDD),
Poseidon for UML et Visual Paradigm for UML. Ces deux derniers sont très
intéressants car ils proposent plusieurs licences, gratuits pour les
particuliers et d'autres licences pour les pro. De quoi se faire la main
avant de sortir le grand jeu :). En libres il y a ArgoUML et dia.

En ce concerne la POO, attention à la tendance à vouloir faire du Java
en PHP, c'est généralement (!) une erreur.

Beaucoups de choses qui nécessiteraient des classes spécifiques en
Java se codent très bien en
PHP/Python/Ruby/Perl/TonLangageDeScriptPréféré avec des listes ou des
hash. Bref, ce n'est pas parce que tu représente quelque chose en
tant que classe ou objet dans tes diagrammes UML que tu doit
nécessairement en faire une classe pendant l'implémentation.

Un sujet de débat, après ça dépend des personnes. Pour ma part la techno
idéale est celle qui se rapproche le plus de la méthode de conception de
l'application, le processus de développement en somme. Donc plus le langage
est objet et mieux c'est. Après tout à quoi bon concevoir son application en
UML si c'est pour se retrouver avec des fonctions et des tableaux ? J'ai
rencontré le problème en passant de C à C++, j'ai vite compris les limites
du C. Il en va de même depuis PHP3... Avec PHP5 on est encore loin de Java
mais on y arrivera, forcément un jour.

Ce genre d'aspect est généralement transversal, donc l'ajouter à la
fin impliquerait trop de modifications dans le code. C'est
typiquement le genre de choses dont il faut tenir compte dès le début
AMHA, et parmi les premières parties à mettre en place - pour moi, ça
fait partie du squelette.

Pour éviter ces désagréments on peut s'aider d'un framework, le squelette
dont tu parles, Fusebox, Seagull... Un bon complément est la bibliothèque
PEAR qui met à disposition des packages. Un peu comme la bibliothèque Java
mais en libre.

Par contre, tu peux très bien commencer avec un module
d'authentification bidon, développer d'autres parties, puis
implémenter effectivement ce module.

Si on veut vraiment développer soi-même un module mais qu'on en a pas
vraiment le temps au moment du développement, on peut simplement se servir
d'une bibliothèque existante (un package de PEAR), le wrappper dans une
classe et utiliser cette classe dans son application. Un jour on peut alors
décider d'adapter son wrapper et de développer son propre module. Par
wrapper j'entends interface entre le module utilisé et son application.
MODULE <- INTERFACE <- APPLICATION. On peut alors remplacer la boîte module
par n'importe quoi. Le système des fameuses briques logiciel.

D'un manière générale, cette méthode (un peu de réflexion avant,
beaucoup d'aménagements pendant) ne fonctionne correctement qu'avec un
bon gestionnaire de version et des tests unitaires aussi automatisés
que possible (ce qui n'est pas toujours évident dans le cas du
développement Web). L'idée est qu'il faut pouvoir réaménager le code
sans souci de casser quelque chose. Un bénéfice secondaire des tests
unitaires est qu'ils forcent généralement à bien modulariser le code
pour le rendre testable.

On pense aussi aux tests de non régression, JUnit de Java qui a été adapté à
PHP (voir package PEAR). Pour automatiser cette procédure je pense qu'il
doit existe des outils, en Java il y a des plugins pour Eclipse par exemple.

Un autre outil intéressant est un 'bug-tracker', si possible lié au
contrôleur de version. Le duo Subversion/Trac est pas mal.

En Bug Tracker libre il y a Bugzilla, je ne connais Trac que de nom. Par
contre je suis entièrement d'accord, pour de la gestion de versions,
Subversion c'est le top. Je l'ai choisi plutôt que CVS. En entreprise
j'utilisais Microsoft Visual SourceSafe (très appréciés dans le jeu vidéo
car Visual Studio est souvent utilisé pour développer).

Le pattern MVC (Modèle/Vue/Controleur) est une bonne application de ce
principe : les 'vues' sont les templates, la logique est dans le
modèle (en POO, généralement des classes 'métier'), et le controleur
- la page php appelée par le client - se charge des interactions
entre vues et modèle. Dans la pratique, il arrive que modèle et
controleur soient confondus, mais ça a souvent pour effet de faire
assumer au modèle des responsabilités qui ne le concerne pas
vraiment. Là, c'est à voir en fonction de la complexité générale de
l'appli et de sa finalité...

Voir le framework Mojavi qui repose sur MVC. Ainsi que Medusa et d'autres
frameworks. Je pense à Fusebox et Seagull. À lire aussi l'article Industrial
Strength MVC du magazine électronique PHP Architect, paru en juin 2003.

--
Jean-Marc.

bruno modulix a écrit/wrote :

La documentation, si, toujours. Mais documention != commentaire. Les
commentaires dans le source ne sont qu'un élément de doc, et
uniquement destinés aux développeurs.

Enfin, bon, AMHA, d'après moi, c'est mon opinion que je partage,

Note d'appréciation du public : 5/5 :)

*** APPLAUSE ***

--
Jean-Marc.

Jeremy a écrit/wrote :

Bonjour,

Bonjour Jeremy. Voilà un sujet intéressant :).

Après avoir réalisé quelques petits projets PHP sans aucune méthode de
développement, je m'apercois que cela devient de plus en plus
handicapant de ne pas suivre de véritable "gestion de projet". En
effet, j'en arrive à des fouillis de code inmaintenable.

Bienvenue à mon ancien club des codeurs fous :). J'essaie de migrer vers un
autre club depuis quelques années :).

C'est pourquoi, je fais appel à votre expérience pour savoir "comment
bien débuter dans un projet PHP". Comment faites-vous lorsque vous
avez un cahier des charges assez imposant pour choisir par quoi
débuter.

L'idéal serait d'avoir un gourou à sa botte, genre Steve McConnell mais...
Tout le monde n'a pas cette chance :). Le plus simple, pour nous pauvres
mortels, est de se tourner vers la communauté, ce que tu fais aujourd'hui,
et de s'intéresser aux livres spécialisés ainsi qu'autres projets solides
comme Mozilla et sa fameuse technologie XUL, ou encore toute la gamme de
logiciels Microsoft ainsi que le projet OpenOffice.org, pourquoi pas.

Pour ma part tout a réellement commencé il y a un peu moins de dix ans quand
j'ai acheté l'ouvrage « Conception et programmation orientées objet » de
Bertrand Meyer. Un pavé de 1200 pages sur le sujet. Rien que ça. Si ça peut
te rassurer je n'ai pas encore terminé de le digérer :). En comme je passais
mes journées à Eyrolles j'ai aussi découvert l'ouvrages « Le guide de
l'utilisateur UML » sans parler du fabuleux « Le processus unifié » qui
présente le RUP. Le processus de développement des trois grands monsieurs
que sont Jacobson, Booch et Rumbaugh. Le livre de Meyer est bien pour
comprendre l'objet, celui sur UML pour modéliser son application, le RUP
pour s'organiser et gérer son projet au mieux. Mais un bon développeur doit
aussi s'appuyer sur des design patterns, présentés dans le fabuleux « Design
patterns » du GOF : Gamma, Helm, Johnson et Vissides. Plus simple que le RUP
il y a aussi la méthode XP qui présente clairement l'intérêt des tests
unitaires et du travail en binôme. Pour résumer le RUP il s'agit d'exprimer
les besoins, analyser, concevoir, implémenter, tester et déployer. Le tout
documenté dans un bel emballage cadeau.

Utilisez-vous des diagramme UML et la programmation objet.
Commencez-vous par établir les prémices de la base de données (s'il y
a lieu). Faut-il tout modulariser? Gérez-vous tout de suite les
aspects tels que l'authentification ou faites-vous cela vers la fin?

Des diagrammes UML ? Oui car ils sont le seul outil que tu peux utiliser
pour expliquer l'architecture de ton projet à quelqu'un qui n'y connaît
absolument rien au développement. Un beau cas d'utilisation (Jacobson) et le
tour est joué. Le client voit des petits bonhommes en train de jongler avec
des boîtes et des flèches dans tous les coins, ils sont contents :). On peut
même s'en servir pour modéliser une base de données à la place d'utiliser un
diagramme ER par exemple. L'astuce consiste à utiliser des stéréotypes. Il
existe d'ailleurs un ouvrage spécialisé sur le sujet : « De UML à SQL ».

Pour la POO l'idéal, en plus de l'ouvrage de Meyer, c'est de passer par la
référence de ton langage. En C++ on parle de Stroustrup. Pour ma part
j'avais commencé à un ouvrage de Liberty. Pour PHP je ne sais pas trop car
cette techno est très très jeune et les ouvrages de références portent plus
sur le langage, cependant des ouvrages plus sérieux voient le jour et on
commence à parler de XP, UML... Un ouvrage pour spécialistes est paru en
français mais il ne couvre que le langage finalement, « PHP avancé » quelque
chose comme ça. Rien à voir avec ce dont tu as besoin.

Pour la BDD il y a l'excellent « Bases de données » du grand Gardarin. L'un
des grand gourous de la BDD dans le monde. Un Dieu vivant pour moi
d'ailleurs :). L'ouvrage le plus clair sur le sujet. Comment modéliser sa
base ? L'architecture d'un SGBD ? Les formes normales d'une base ? En ce
moment j'épluche aussi les articles du site SQLpro, une référence
francophone sur le sujet. Des articles de fond sur certains sujets épineux.

Modulariser ? Oui au maximum, tant qu'on sait ce qu'on fait. À trop
modulariser on finit par fragmenter son système d'information et à le rendre
tout bonnement inexpoitable. On se retrouve alors avec des modules qui sont
incapables de communiquer entre eux faute de pouvoir utiliser telle ou telle
interface. Des modules, des interfaces. Un module se sert de l'interface
d'un autre module pour communiquer avec lui. Il n'accède jamais au module
directement. Ainsi si le module est amené à changer au court du temps, et
cela arrive toujours, le module qui utilise l'interface n'a rien à changer.
On adapte l'interface (voir les Design Patterns) au nouveau module et le
tour est joué.

Si tu parlais de normaliser une BDD, voir l'ouvrage de Gardarin ou les
références sur le sujet (SQLpro au hasard et certains articles de PHPBuilder
si mes souvenirs sont bons) de la normalisation. Le danger c'est de faire
chuter dramatiquement les perfs, à trop rendre sa base atomique on finit par
engluer le serveur et à se retrouver avec 10 requêtes plutôt que 2.
Jointures croisées et autres tortures de l'esprit.

« Modulariser » en terme d'architecture web c'est aussi séparer ton
application en couche. On parle d'architecture n-Tier, à plusieurs couches.
Une couche applicative, une couche présentation... Il existe des tas de
modèles mais le plus répandu est sans doute MVC. MFC de Microsoft est une
variante de MVC, qui nous vient de Smalltalk. Quelqu'un t'a expliqué de quoi
il retournait il me semble. Le danger avec PHP c'est qu'il est embarqué à
HTML, tu peux donc tout te permettre et même de mélanger les couches. C'est
ce que font la majorité des développeurs d'ailleurs... On ne leur laisse pas
forcément le choix à vrai dire car PHP n'est qu'un langage et manque d'un
framework officiel justement comme on peut en trouver chez Sun/Java ou
Microsoft/.NET. D'où sa difficulté à percer dans le milieu des hautes
sphères de la création :).

Peut-être que certains voudront bien me faire part de leur expérience
dans ce domaine ou me diriger vers des liens.

Voilà ça n'est pas facile de résumer une expérience de quelques 8 ans de
réflexion sur le sujet. Et dire que certains font ça depuis 20 ans... Ça
fait peur ! Déjà avec les références que je t'ai données tu as de quoi te
torturer l'esprit pour les dix prochaines années. Tu dois aussi pouvoir
trouver des articles qui résument ces ouvrages sur le web.

--
Jean-Marc.