Comment justifier l'Orienter Objet.

Bonjour,

Actuellement, je dois admettre que je ne suis pas vendeur. Je suis programmeur (à mon compte). Récemment, j'ai un client qui me donne un peu de fil à retordre.

Mais je comprend: Ce client a toujours développée elle-même en php procédural avec des bases de données MySQL/MyISAM simples, ce qui lui permettait une certaine cadence de développement, mais surtout une constance dans l'avancement de son développement.

Ce client étant surchargée, j'ai recu le mandat d'un de ces projets. Dans les grandes lignes, il s'agit d'une boutique en ligne.

Donc je commence à programmer mes Objets, mes Factory, modéliser la base de données. Puis soudain, elle voit les heures augmenter, mais ne constate que bien peu de progrès "visible".

Pris de panique, on me demande d'arrêter le projet.



J'ai beau lui donner des arguments, rien à faire: C'est trop long, et les craintes que je dépasse son budget ou les échéances (que j'ai toutes deux acceptés pourtant) deviennent trop grandes.


Exemple d'arguments/réponses:

L'orienté objet est plus facile à maintenir:
- Je n'ai pas de problème à maintenir mes autres sites

La gestion des erreurs est meilleure:
- PHP log les erreurs de mes autre sites.

Le code sera testable unitairement
- J'ai jamais eu besoin de ca

La base de données supportera les transactions et l'intégrité référentielle, ce qui donnera une boutique beaucoup plus sécuritaire.
- Sur mes autres sites, j'ai des "statut" (?) qui m'indique ce qui s'est mal passé.

L'orienté objet c'est comme la peinture: c'est plus long de poser le ruban-masque, et pendant qu'on pose ca, la peinture avance pas, mais après l'application de la peinture est plus rapide.
- Ca la convaincu une fois, mais le projet à été interrompu une seconde fois.

Le code sera en grande partie ré-utilisable pour de futur projet.
- Ca n'appaise en rien ses inquiétude pour le projet actuel.



... donc comme vous pouvez vous imaginez, je passe presqu'autant de temps à la rassurer qu'à avancer. Ce qui n'est pas pour aider.

Là je viens de simplement lui dire quelque chose dans la veine de:
"Vous recherchiez un programmeur d'expérience, ce n'est pas mon premier projet et je sais où je m'en vais. Je suis en mesure de respecter les budgets et les échéanciers, à condition que vous n'interrompiez pas le projet sans arrêt."




Bref, comment faites-vous pour gérer des clients qui:
- ont assez de rudiment pour saisir le langage PHP et s'intéresser à l'avancement technique
- n'ont pas assez de connaissances pour bien comprendre les fondements de l'orienté objet pour les projets ayant une certaine ampleur, et qui en reviennent toujours à comparer avec le procédural.


Merci pour vos commentaires et suggestions, car je commence vraiment à trouver mon travail de plus en plus frustrant et désagréable.

Elle a cependant raison sur une partie : puisqu'elle n'a pas de compétences suffisante, elle ne pourra pas maintenir elle même ton application.

Si tu as accepté son budget et ses délais... ta méthode de développement ne devrait pas être un problème côté client si ce n'était pas explicitement prévu dans le cahier des charges.

Il y a peut-être une raison cachée : peut-être voulait-elle pouvoir mettre le nez dans le code pour des évolutions futures et elle comprend qu'elle ne pourra plus le faire...

Sinon, c'est apparemment plus un problème de confiance que de technique. A mon avis ce n'est pas le mode objet qu'il faut appuyer mais ta capacité à mener ce projet à bien dans les délais impartis.

C'est un point, sauf que cette personne fait appels à plusieurs sous-traitants.
Et on parle d'un site transactionnel, qui sera assurément attaqué.

As mon avis lorsqu'il s'agit de la sécurité financière des autres, il n'y a pas place à négociation. Déjà que j'ai du oublier les tests unitaires...

Je n'ai jamais caché vouloir y aller par objet. Donc si la personne voulait faire de l'auto-maintenance, ca aurait du ressortir avant même le début du mandat.

----

Et ouais, j'ai vraiment l'impression qu'il y a un sévère manque de confiance au niveau des prévisions budgétaires.

Citation:

---

Donc je commence à programmer mes Objets, mes Factory, modéliser la base de données. Puis soudain, elle voit les heures augmenter, mais ne constate que bien peu de progrès "visible".

---

A mon avis, tout est dit. A toi de modifier ton développement pour montrer que ça avance. Fixe-toi des itérations de 2, 3 semaines et montre les nouvelles fonctionnalités apportées à ton client à la fin de chaque itération. Si ton client a de la visibilité sur ton avancement alors il aura confiance et alors importera moins la méthode de développement, objet ou procédural...

Un peu de lecture: http://agilemanifesto.org/principles.html

Tu as tout à fait raison. Et c'est ce que j'essaie de faire. Mais en même temps j'ai même pas encore les maquettes de design...

Mais s'en est rendu à un point ridicule: Hier j'ai du donner 2 compte rendu sur mon avancements. Le deuxième après seulement 54 minutes de travail "compté" du premier.

Alors vous imaginez bien que dès que j'arrive devant un "gros" morceau abstrait, exemple: modéliser et créer l'objet "Produit", ca fait un bloc de temps que le client ne comprend pas: ca n'avance pas.

Mais là tu travaille sur quelle page ? Visiblement aucune ... Moi cette page la elle m'aurais pris 2h à faire, et depuis 3h tu n'a rien fait.

Bref, je crois que c'est un cas désespéré. Heureusement que j'ai d'autres clients un peu plus confiant.


Note:
Ouep, je connais le développement AGILE, j'ai aussi fait un atelier SCRUM... Deux chose que le développeur connais et que le gestionnaire ignore totalement. dommage.
Dire que je suis plus de 40% en avance sur ma SFT (Structure de Fractionnement des Travaux, je sais pas si vous utilisez cet outil de gestion en France)... Vu comment tourne les choses, je vais probablement perdre le projet, que j'aurais terminé bien en dessous du budget. C'est beau la vie. :aie:

L'objet ? Un tank pour tuer une mouche. Allez trouver un tank au
prix d'un tape mouche :-)

C'est une manière de voir les choses et je peux comprendre ta cliente.

Je pense que pour justifier l'utilisation de la POO, il faut qu'il y aie un réel
besoin de POO, et pour moi cela signifie entre autres:

1) Plusieurs programmeurs qui travaillent en coopération (la POO aide à
séparer les choses et limiter les risques)

2) Une stratégie de modélisation qui vise à réutiliser du code dans d'autre
projet.

3) La nécessité (et non la possibilité) de faire des tests unitaires.

Faire de la POO parce que la POO est potentiellement plus robuste n'est
pas un argument économiquement défendable pour un projet.

Le problème n'est pas que ce soit "trop cher", car je suis tout à fait dans les budgets, et je peux utiliser des composants déjà fait & stable que j'ai créé pour d'autres clients.
Le problème est que la progression de l'avancement ne soit pas constante.

Autrement dit, si on calcule l'avancement avec une bête règle de 3, au début du projet le résultat semble indiquer que le projet sera énormément plus long.

Salut

J'ai lu le topic, une peu en diagonal je l'avoue :mrgreen:

Il y a un aspect qui selon moi n'a pas été évoqué (ou pas vraiment), c'est de faire de la POO dans le but que le code soit réutilisable, esprit FrameWork j'entends.

Comme ça, j'aurais à peu près la même réaction que ton client.
Enfin, ça dépend vraiment du code (POO) que tu as fais.

Si par exemple ce code final pourrait être réutilisable afin de réécrire tous les anciens sites (codés en procédural) et les futur projets, cela de manière très rapide, avec tous les avantages que ce code POO offrira (plus de sécurité, plus de souplesse, débug plus rapide, etc, etc, j'en passe et des meilleurs) ... alors dans ces condition l'investissement peu valoir le coup.

Mais si ton code, même POO n'est pas si réutilisable que ça, alors peut être que je dirais que ça ne sert pas à grand chose.

La POO à mon sens (c'est purement mon avis) a un réel intérêt pour un projet d'assez grande envergure, ou alors les besoins seraient très spécifique, mais là où ça vaut vraiment le coup, c'est quand il faut déployer plusieurs projets basés sur ce même code POO.


J'en sais rien si le projet de ton client justifie de faire de la POO, mais comme ça, pour un site e-commerce ça semble quasi indispensable, au moins en partie.
Maintenant, reste à savoir jusqu'à quel degrés la POO à été poussée, car même à ce niveau, il a POO et POO.


Maintenant, ton client n'a peut être pas toutes les compétences pour juger de ton travail, c'est ce qui m'a l'air d'être le cas vu ses réponses.
S'il ne veut pas de la POO, alors faut pas faire de la POO, car comme dirait l'autre, le client est roi.
C'est comme une voiture, si cela ne le dérange pas de tourner la manivelle pour la faire démarrer, qu'est ce tu y peux ?

Est ce que cela figure dans le cahier des charge que le projet est programmé Objet ?

Hehe, l'exemple de la voiture m'a bien fait rire ;)

Je suis tout à fait d'accord avec le reste d'ailleurs...

Il y un argument qui me gêne : en quoi la POO apporte t'elle de la securité ?

Citation:

---

Envoyé par sabotage

Il y un argument qui me gêne : en quoi la POO apporte t'elle de la securité ?

---

Oui, dans l'absolu la POO n'a rien avoir avec la sécurité ;)

Mais dans la pratique, et pour un projet en Php, je pense qu'on fait tous quelque chose de plus au moins automatisé pour filtrer/épurer les données extérieurs (Un voir plusieurs Objets dédiés, pourquoi pas).
Ne serait-ce que ça.

En tout cas, la sécurité dans ce monde de brut qu'est le Web prend une place énorme dans le code, et il me semble que si on fait un projet Orienté Objet, cet aspect prendra une grande place.


En résumé, la POO offrant une souplesse et une maniabilité que n'offre pas la mode procédural, l'aspect sécurité pourra (ou pourrait) être abordé de meilleurs manière.
Donc, le projet offrira une sécurité plus poussée, car plus fine.
M'enfin, c'est théorique, et abstrait, tout comme la POO d'ailleurs :mrgreen:

En fait c'est simplement que, dans mon cas, mes outils de sécurisations sont tous prévu pour être intégrer à des projets orienté objet.

Par exemple j'ai une classe qui étend PDO et qui me permet de prendre en charge toutes les statistiques et toutes les erreurs lié aux requêtes aux bases de données.

Ce serait tout à fait possible de faire l'équivalent en procédural, seulement ma palette d'outil est en POO. Donc pour moi, ca représente un énorme gain de temps dans un nouveau projet, et ces différents outils sont compatible et adaptable avec l'ensemble des projets que j'aborde en POO.

Bref, non, la POO n'est pas "plus sécuritaire", mais en utilisant la POO, je met à ma disposition beaucoup d'outils que j'ai déjà développé. (Alors que probablement d'autres personnes ont des librairies procédurales qui pourrait faire la même chose, mais ce n'est pas mon cas)

Citation:

---

Par exemple j'ai une classe qui étend PDO et qui me permet de prendre en charge toutes les statistiques et toutes les erreurs lié aux requêtes aux bases de données.

---

Ce n'est pas juste pour contredire (on est d'accord ;) ), mais ici tu parle de la gestion des erreurs, des outils qui auront pour but de repérer les éventuels erreurs, au bout, le but final est de rendre son code plus robuste une fois les erreurs réparées.
A mon sens ça n'a pas vraiment de rapport avec la sécurité, même si la frontière entre les 2 est par moment très mince.

On peu très bien mettre en place une gestion des erreur hyper poussée, et à coté de ça une vrai passoire en terme de sécurité, et inversement.

L'exemple typique à mon sens vient de la directive display_errors du php.ini.
A On, ça permet de voir les messages d'erreurs donc d'améliorer le débuggage, mais de l'autre, ça diminue la sécurité.

Mais on sera d'accord qu'avec l'Objet, on pourra traiter le cas plus finement, donc avoir une gestion des erreurs plus poussée sans détériorer la sécurité.