Quelle est la solution PHP la plus obscure que vous ayez utilisée ?

Quelle est la solution PHP la plus obscure que vous ayez utilisée ?
Scripts, Frameworks, CMS maisons ou langages PHP-Killer ?



PHP est un langage très populaire, et il existe autour un vaste écosystème d'applications de qualité, libres et gratuites.

Mais certaines entreprises préfèrent utiliser des Framework/CMS fait-maison pour augmenter leur productivité.

Ces solutions évoluent souvent en fonction des projets jusqu'à devenir des usines à gaze insupportables, des horreurs « sans nom » copiées et modifiées à l'arrache pour chaque projet.

Souvent, le néophyte qui intègre l'équipe de développement passe des semaines à patauger dans le code (de surcroît mal- ou pas du tout documenté) jusqu'à voir la lumière au bout du tunnel ou finir par quitter avec une addiction aux antalgiques.

Mais il existe - apparemment – encore pire : des entreprises qui créent des pseudo-langages écrits de PHP et les vendent en tant que « PHP-Killer ».

C'est l'expérience dont témoigne -pour de vrai mais de manière satyrique – un dénommé « Christian » qui a intégré une entreprise en qualité de Développeur PHP... pour y découvrir « BobX », le « parser dans le parser » payé très cher et utilisé dans tous les projets de développement de l'entreprise.

En résumé, Christian découvre petit à petit qu'il ne s'agit en fait que d'une surcouche de PHP où la plateforme sous-jacente est bien cachée.

Le développeur, consciencieux et désireux de faire faire des économies (de temps) à son nouvel employeur, arrive à hacker « BobX » pour reprendre le travail en PHP classique et se simplifier la tâche.

Content, et sur le point de faire un rapport à son patron Brian, ce dernier arrive, lui lance fou de rage et demande : "J'ai reçu un email de Bob [NDR : Le développeur de BobX], il dit que tu as piraté son serveur de production, est-ce vrai ?"

Christian a beau expliquer la situation, rien n'y fait. Bob a même menacé de rompre le contrat et de débrancher tous les serveurs et toute l'infrastructure.

Double peine, le développeur a même du réécrire tous ses codes en « pure » BobX avant de quitter l'enteprise.

« Et rejoindre le rang de tous les développeurs qui n'ont pu rester à la page et utiliser BobX », conclue le billet qui raconte cette malheureuse histoire.


Source : Lire les détails de l'histoire sur thedailywtf.com


:fleche: Et vous, parlez-nous des solutions PHP les plus obscures et les plus mal faites que vous avez dû utiliser.

:fleche: Avez-vous croisé un BobX dans votre carrière ?


Lire aussi :

:fleche: Avez-vous inventé des termes que seuls vous et votre équipe comprenez ? Drôles ou techniques, expliquez-les nous

Les rubriques (actu, forums, tutos) de Développez :

:fleche: PHP
:fleche: Langages




En collaboration avec Gordon Fowler

Mon dieu... j'ai été lire l'article complet... Personnellement je n'ai jamais eu a faire a quelque chose du genre... Mais je trouve ça extrêmement exagéré ... Faire une sur-couche PHP et vendre ça comme un truc "mieux"... A la limite... Mais que du coté de l'entreprise on ne fait pas d'analyse poussée ou un minimum de recherche pour détecter la supercherie... surtout au moment ou la chose intervient... WAW

9 fois sur 10 PHP est utilisé en entreprise pour son côté "gratuit" et "facile". Faire ce que tu dis, c'est accepter de dépenser plus d'argent dans un truc ou on a pas voulu en mettre à la base.

J'ai bien ri en lisant le truc, l'histoire d'un mec qui fait de l'argent sur le dos d'une entreprise crédule.

Je ne trouve aucune information sur ce "BobX". Quelqu'un a trouvé le site du développeur de cette daube?

La meilleure chose que ce dev avait à faire, c'était de partir faire pour faire réellement de la programmation et pas se casser les dents sur une pseudo poubelle comme ce machin.

En tout cas, bravo au créateur de cette arnaque en puissance, car en plus d'avoir vendu ce truc, il a pondu un contrat qui semble unilatérale quant aux droits d'utilisations. :ccool:

Outre le côté exagéré et marrant de l'histoire, le méta-langage dans le langage est rarement source de bonnes choses quand s'est développé dans le cadre d'un produit unique ou d'une entreprise (et donc hors frameworks très complets pour diffusion grand public comme le zend framework ou SEAM , Hybernate dans le monde Java). Pour avoir travaillé dans le développement web, j'ai du passer par les CMS les plus courants... Et bien entre Typo3 et son méta-langage de templates et Drupal et ses templates entièrement en php natif avec injection de variables prédéfinies de blocs de contenus... mon choix est rapide.

J'avoue n'avoir pas testé la version 5 de Typo3, ayant migré vers Drupal au moment de la sortie.

(bon ok, Drupal a également une interface d'administration nettement plus "user-friendly", ma comparaison des deux systèmes est très subjective)

@badack : Bobx c'est surement un faux nom de framework.


En tout cas j'ai déjà rencontré ce cas de figure 2 fois, une fois en PHP, une fois en JAVA.
Et c'est pas forcément une arnaque de la part d'un gars, c'est bien souvent un type qui a une idée lumineuse tout seul dans son coin et qui réussit à l'imposer comme standard.

Parfois c'est aussi la boite qui, par souci de mutualisation (la sacro sainte mutualisation édicté par les achats), impose à un service de généraliser son fabuleux framework qui a permis la réussite du projet X.

En tout cas, la réaction du boss dans l'histoire me rappelle le théorème du singe :

http://fr.wikipedia.org/wiki/Th%C3%A...%A8me_du_singe

Où, comment nait la culture d'entreprise.

J'ai cette expérience actuellement sur ma mission avec un framework .net développé et mutualisé pour plusieurs équipes... :calim2:

J'avoue que parfois, j'ai vraiment envie de coder en .net standard, j'irais plus vite et le résultat serait moins buggé même s'il nécessiterait un peu plus de codage à la main... quoique... :cry:

De plus, le théorème du singe s'applique merveilleusement bien à l'équipe chargée du développement de ce framework... :aie:

Il a pas mal de boîte qui fonctionne sur ce principe là malheureusement: se baser sur un "framework maison", héritage de plusieurs développeurs successifs au niveau plus ou moins douteux.
Personnellement on m'a imposé une fois d'utiliser un ensemble de librairies propres à une boîte(pas en PHP, mais le souci est le même) :
L'auteur n'était plus dans la boîte depuis un moment, le tout très peu documenté avec quelques bugfoots (pour reprendre une expression que j'ai pu trouver sur développez il y a quelques jours xD) qui arrivent de manière totalement aléatoires et que j'ai fini par patcher "à l'arrache" (comprendre des "return" quand des objets n'étaient pas alloués...) faute d'avoir le temps de faire mieux.
Au final tellement de temps perdu, pour avoir accès à quelques fonctionnalités qu'on pourrait retrouver pour la plupart sur des lib open-sources solides et très simples à prendre en main.

Bref, pour ceux qui se retrouvent dans ce cas là, et qui aiment développer, je leur conseille de remettre leurs CV à jour et de reprendre leur recherche d'emploi. Ou devenir fou, au choix ;p

Le pire cas que j'ai connu dans le genre, c'était avec le "CMF" Nectil. En gros, leur système de requêtes pour l'accès à la base de données reposait sur ce qu'ils appelaient le "NQL" (Nectil Query Language), une sorte de couche d'abstraction basée entièrement en XML. Je bossais pour une boite qui reposait sur cette solution. Et oh combien de fois, je n'ai pas eu envie de faire sauter ce mécanisme pour interroger correctement la base de données au travers des API standards et répandues. Finalement, l'emploi de cette solution a été l'un des critères me décidant à quitter mon emploi de l'époque.

Le plus extrême, c'est la volonté du développeur de cacher la vérité à l'entreprise cliente.

J'ai bosse sur un logiciel d'un éditeur assez réputé dans son domaine qui utilise massivement des frameworks maison.
Un framework utilisant un meta langage XML pour parser des documents et les intégrer dans le système. Après l'avoir compris, j'avoue qu'il est plutôt bien fait.

Un autre pour customiser les interfaces graphiques, utilisant plusieurs couches de javascript. Là par contre j'ai beaucoup moins adoré car j'ai jamais compris l'utilité de la chose et c'était beaucoup trop complexe.

Avec tous les très bons frameworks opensource aujourd'hui disponibles, faire le sien est un pari casse gueule.

SI la documentation suit c'est tout à fait admissible, mais open source et documentation de qualité sont trop rarement copains.

Citation:

---

Envoyé par _skip

SI la documentation suit c'est tout à fait admissible, mais open source et documentation de qualité sont trop rarement copains.

---

Le framework maison en javascript était super mal documenté et la plupart des dev originaux (sauf 1 senior) s'étaient barre depuis des années. Crois moi c'est très pénible ! :D

De mon côté, je bosse sur un pseudo framework delphi, dont plus personne ne sait comment il marche !! Et bien sur, pourquoi avoir de la documentation ?? 8O
Donc, au lieu de développer rapidement, on perd tout le temps son temps.
Encore hier, 2 heures pour mettre une combobox à enable et la remplir !!!
La joie quoi :)

Bonjour, à contrario de ce que s'est dit,
j'ai développé un framework maison .
Le contexte :
Une grande entreprise ou les développements sont de plus en plus bannis (progiciles) ou sous-traités en INDE. Je me retrouve dans un secteur ou les besoins ne sont plus satisfaits et seulement quelques personnes savent développer.
Bien obligé d'optimiser la façon de développer ....
Et de fait, c'est devenu un standard .

L'idée de base, les données d'un secteur de conception sont structurées dans des fichiers Excel . Des tableaux la plupart du temps .
Donc, les applis qui peuvent remplacer Excel sont structurées autour de tables SQL ressemblant à leurs données initiales. Et le dialogue est souvent ramené à un échange entre un fichier Excel et l'application (ce qui n'est pas forcément simple)
Ce fonctionnement est réducteur (je sais) mais marche assez bien ... :aie:

Composé de quelques classes ; 8-)
Afficheur : s'occupe des affichages HTML (les interfaces et les calques sont aussi standardisés)
des tableaux, des saisies, etc ...
Controleur : s'occupe de contrôler tous les attributs des classes correspondantes aux tables SQL (et les autres)
Persistance : accès aux bases MYSQL (moins technique que PDO qui n'interface pas grand chose ... )
Fichier : toutes les manipulations de fichier (téléchargement, etc ...)
ExcelCom : toutes les manips COM avec EXCEL
ExcelPear : toutes les manips PEAR avec EXCEL
etc ....

Bref, ceci réduit énormément le travail technique et permet de se concentrer sur le travail fonctionnel avec le client (interne) :ccool:
Evidemment, peu de développeurs ... 4 ont repris ce framework
et quelques pressions amicales pour le faire évoluer (Ajax notamment) :calim2:

C'est ouvert, mais le management n'a pas les compétences pour juger de la pertinence de ce framework, ce qui n'empêche pas le risque autarcique :P

Salut à toutes et à tous