Methode de developpement PHP

Etienne SOBOLE a écrit/wrote :

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...

Doxygen. Doxygen. Doxygen. Ce logiciel a changé ma vie quand je l'ai
découvert il y a quelques années. J'ai commencé par documenter mes projets
DOS avec lui et depuis je ne le lâche plus. Biensûr pour PHP il y a PHPDoc
et Javadoc en Java mais Doxygen... Arf ! Doxygen se base bien entendu sur la
syntaxe Javadoc. Ce qui le rend indispensable pour un développeur
C/C++/Java/PHP. Une syntaxe unique, le pied.

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...

Un bon outil propose forcément une syntaxe particulière pour « marquer » un
code, on peut alors déterminer par exemple si il y a un bogue, «
deprecated »... Voir Doxygen. Microsoft m'a bien fait rire en introduisant
une telle syntaxe dans .NET. D'après eux c'était une révolution... Bah
voyons.

--
Jean-Marc.

__marc.quinton__@aviation-civile.gouv.fr a écrit/wrote :

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.

Pour ma part j'ai opté pour Fusebox que j'ai découvert il y a quelques
années avec Coldfusion alors que je cherchais un framework pour PHP. J'ai
choisi ce framework car il correspondait à 90% à celui que j'avais développé
en interne.

--
Jean-Marc.

Bruno Desthuilliers a écrit/wrote :

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...

Brian Lozier es-tu là ?
Oui je suis là ! http://www.sitepoint.com/article/beyond-template-engine :)

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.

Attention PEAR n'est pas réellement un framework, c'est plus une
bibliothèque de packages qu'autre chose. Et c'est d'ailleurs son principal
intérêt, on peut l'intégrer à n'importe quel framework. On est loin de
Struts de Java par exemple.

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...

Attention il ne faut pas confondre commentaires et doc. Les commentaires
sont bons pour comprendre le code mais pour utiliser le code il faut le
documenter, on en revient à Javadoc/PHPdoc.

--
Jean-Marc.

Jeremy a écrit/wrote :

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).

Perso quand j'ai découvert PHP il y a 4 ans... Je me suis franchement
demandé à quoi pouvait bien servir un système comme Smarty. Après tout c'est
bien marqué dans le manuel : « PHP est embarqué à HTML ». Alors à quoi bon
utiliser Smarty ou équivalent ? Je me suis toujours dit que cela ne servait
à rien et encore aujourd'hui j'ai des doutes, on peut avancer des arguments
en faveur de ces technologies mais aucune ne remplacera PHP. Pour moi la
majorité de ceux qui les utilisent ne comprennent pas ce qu'ils font. PHP
est un langage. HTML permet de structurer une page. On peut même les mettre
en forme avec CSS. À quoi bon rajouter un nouveau langage, une nouvelle
technologie comme Smarty alors que PHP - est justement fait pour ça. On se
retrouve alors avec 2 langages alors qu'on en a besoin que d'un.

Un excellent article qui m'a rassuré sur mes pensées :
http://www.sitepoint.com/article/beyond-template-engine

Seul hic à utiliser PHP, un problème de sécurité car cela veut dire qu'un
modèle peut faire tout et n'importe quoi, supprimer un répertoire du serveur
par exemple. Heureusement le moteur peut inhiber certaines fonctions PHP,
ouf ^^'.

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.

Effectivement. PEAR possède de nombreux packages et est très bien documenté.
Je l'ai découvert avec le package Mail par exemple. Et il ne faut pas
s'attendre à voir PEAR disparaître car l'objectif de Zend avec PHP5 c'est
d'introduire une bibliothèque à la hauteur de celle proposée par Sun pour
son Java. Une Standard Library comme on dit. En C++ on a la STL, en PHP il y
aura un PEAR-quelque chose. À voir avec PHP6 sans doute. Enfin espérons car
niveau performances PEAR c'est la chute libre, pur PHP oblige.

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

Le problème c'est que PHP ne nous met pas dans la bonne voie. Voyez le
manuel, bon à mettre à la poubelle tellement le code de base est mal
documenté. On se demande toujours ce qu'une fonction retourne comme valeur
et à quoi peuvent bien servir les paramètres. D'où l'intérêt de
Doxygen/Javadoc. La documentation générée met bien en évidence les valeurs
retournées, les paramètres, ce que fait une fonction... On peut même
embarquer de la doc HTML dedans question d'avoir une documentation très pro.
Un bon exemple... PEAR ! Documenté au maximum, c'est dans le PEAR Coding
Standards. J'ai pas dit le PIRE Coding Standards, hein :).

--
Jean-Marc.

Jean-Marc Molina wrote:

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...

Le framework ne fait pas tout, et peut poser des problèmes par lui-même
(lourdeur, complexité, ...). Mais la démarche dont je parle n'exclue en
rien de s'appuyer sur un framework existant (je préfère quand c'est
possible et que ça convient). Par contre, je ne vois guère en quoi ça
réduit les risques - ça peut même en être un (dans la rubrique 'techno
mal connue').

Mais en passant par
là on apprend souvent beaucoup, seulement certains y restent !

Eh oui, c'est la dure loi de la vie...

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.

A part dia (que j'aime beaucoup pour sa simplicité et le fait qu'il se
contente de faire des diagrammes), j'ai une sainte horreur de tous ces
outils, qui sont souvent contre-productifs AMHA - en tous cas sur des
petits/moyens projets. Tant que le code n'est pas opérationnel, un
diagramme n'est qu'une ébauche d'organisation du code, et une fois qu'il
est opérationnel, le diagramme ne peut que donner une vision d'ensemble
de l'architecture - d'autant qu'UML est peu apte à exprimer certains
mécanismes courants dans les langages que j'utilise (fonctions anonymes,
closures, meta-programmation etc).

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 ?

Pour avoir une implémentation propre et bien organisée ?-)

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.

<troll>
Hélas :(
</troll>

(snip)

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,

pourquoi "aussi" ? C'est exactement à ça que je pense !-)

JUnit de Java

qui a copié une bibliothèque Smalltalk !-)

qui a été adapté à
PHP (voir package PEAR).

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.

Certainement plus souple que Bugzilla !-)
Un des intérêts de Trac est l'intégration Tracker/Wiki, qui permet de
gérer conjointement le suivi, les discussions et la doc.

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

Jean-Marc Molina wrote:

Bruno Desthuilliers a écrit/wrote :

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...

Brian Lozier es-tu là ?
Oui je suis là ! http://www.sitepoint.com/article/beyond-template-engine :)

Pile poile !-) Merci Jean-Marc.

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

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.

Merci beaucoup Jean-Marc pour cette réponse qui est comme d'habitude
(d'après les archives que j'ai pu lire) très complète et intéressante ;-)

J'ai de quoi me plonger dans quelques années de réflexion profonde sur
la conception. Mais, ca ne va pas être facile de changer mes habitudes.

Je viens en effet, suite à tes orientations, de tomber sur un excellent
article sur MVC/PHP de Serge Tahé
(http://tahe.developpez.com/web/php/mvc/) et bien ca fait peur...

J'aurais allégrement "expédié" l'exercice de calcul d'impot pris en
exemple dans l'article, en quelques dizaine de lignes de code simple.
Quand, je vois la solution proposée en MVC, c'est certainement un
meilleur code pour la maintenance, mais c'est un code effrayant (enfin
pour l'instant, peut être qu'après plusieurs lectures, ca ira mieux :-) )

Ca m'a permis de comprendre également, que je faisais peut être une
sorte de MVC comme Monsieur Jourdain (qui n'a pas la réputation de Steve
McConnell) mais à ma sauce. Mon code applicatif est bien séparé du code
de présentation. Cependant, j'ai surement laissé passé des aspects de
conception important sous prétexte que les problèmes sous-jacents ne
s'était jamais posé à moi. Du genre, quand je concois pour un type de
SGBD, je ne prévois pas qu'il soit possible de changer de type de SGBD
ou de méthode de stockage de données plus tard. C'est certainement une
erreur, et je vais grâce à tous vos conseils y remédier de ce pas.

Merci encore à tous pour vos infos.

--
Jérémy

Je viens en effet, suite à tes orientations, de tomber sur un excellent
article sur MVC/PHP de Serge Tahé
(http://tahe.developpez.com/web/php/mvc/) et bien ca fait peur...

J'aurais allégrement "expédié" l'exercice de calcul d'impot pris en
exemple dans l'article, en quelques dizaine de lignes de code simple.
Quand, je vois la solution proposée en MVC, c'est certainement un
meilleur code pour la maintenance, mais c'est un code effrayant (enfin
pour l'instant, peut être qu'après plusieurs lectures, ca ira mieux :-) )

je ne crois pas que l'exemple du calcul d'impots soit a prendre
pour argent comptant. Ici, les principales composantes du
calcul simplifié apparaissent plus nettement :

http://minilien.com/?ktnr9tkQlu

on voit :
* les tranches,
* les pourcentages,
* les deductions,
* le bareme par années.

biensur, cet exemple ne gere pas tout les mecanismes d'affichages
et de formulaires complexes.

je ne crois pas que l'exemple du calcul d'impots soit a prendre
pour argent comptant. Ici, les principales composantes du
calcul simplifié apparaissent plus nettement :

http://minilien.com/?ktnr9tkQlu

on voit :
* les tranches,
* les pourcentages,
* les deductions,
* le bareme par années.

biensur, cet exemple ne gere pas tout les mecanismes d'affichages
et de formulaires complexes.

Euh, en fait je ne me suis pas du tout intéressé à la justesse de calcul
d'impot de l'exemple, mais plutôt à la méthode utilisé pour résoudre le
problème. A la rigeur, si c'était un simple calcul de TVA, je pense que
le principe du MVC serait identitique et (pour moi) tout autant compliqué.

Mais merci quand même pour le lien et la classe décrite avec.

--
Jérémy

(snip)

Je viens en effet, suite à tes orientations, de tomber sur un excellent
article sur MVC/PHP de Serge Tahé
(http://tahe.developpez.com/web/php/mvc/) et bien ca fait peur...

Extrait de la conclusion:
"Nous nous sommes approchés dans ce chapitre de la philosophie [de]
Struts, bien connue des développeurs Java"

Effectivement, il y a de quoi avoir peur... Si c'est pour faire aussi
compliqué que Java, je ne vois pas l'intérêt d'utiliser PHP - à ce jeu
là, Java sera toujours gagnant !-)

J'aurais allégrement "expédié" l'exercice de calcul d'impot pris en
exemple dans l'article, en quelques dizaine de lignes de code simple.
Quand, je vois la solution proposée en MVC, c'est certainement un
meilleur code pour la maintenance,
mais c'est un code effrayant (enfin
pour l'instant, peut être qu'après plusieurs lectures, ca ira mieux :-) )

En l'occurrence, je ne suis que moyennement convaincu !-) - pas par le
pattern MVC, juste par l'implémentation proposée. J'ai comme
l'impression qu'il y a pas mal de complexité inutile.

Ceci étant, un problème récurrent dans les tutoriels OO est que le code
de la version OO parait à peu près toujours inutilement compliqué. C'est
parfois effectivement le cas, mais le plus souvent, c'est lié au fait
que, pour un tutoriel, on choisit plutôt un problème simple - qui donc
peut se résoudre bien plus simplement sans toute la complexité de
l'approche objet. Les gains (en termes de maintenabilité) d'une bonne
architecture OO ne deviennent manifestes que sur certaines applis de
toutes façons complexes, et nécessitant pas mal d'évolutivité.

Ca m'a permis de comprendre également, que je faisais peut être une
sorte de MVC comme Monsieur Jourdain (qui n'a pas la réputation de Steve
McConnell) mais à ma sauce. Mon code applicatif est bien séparé du code
de présentation.

C'est déjà ça. Reste, le cas échéant, à séparer la partie du code qui
analyse les requêtes, les valide, gère les appels aux objets métier[1] -
bref, le(s) contrôleur(s) - des objets métier[1] eux-même - le(s)
modèle(s).

[1] ... ou a leur équivalent si ton code est procédural. Une conception
objet n'implique pas nécessairement une implémentation à base de classes
et d'objets (au sens 00).

Cependant, j'ai surement laissé passé des aspects de
conception important sous prétexte que les problèmes sous-jacents ne
s'était jamais posé à moi.

YAGNI ? (trad: You Aint Gonna Need It)

Avant d'implémenter une mécanique complexe, demande toi si le problème
qu'elle est supposée résoudre est vraiment un problème.

Du genre, quand je concois pour un type de
SGBD, je ne prévois pas qu'il soit possible de changer de type de SGBD
ou de méthode de stockage de données plus tard. C'est certainement une
erreur,

A tu un cas d'utilisation impliquant de devoir changer de SGBDR ou de se
passer de SGBDR ?