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


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

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


Lire aussi :

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 :

PHP
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

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.

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.

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

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

Composé de quelques classes ;
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)
Evidemment, peu de développeurs ... 4 ont repris ce framework
et quelques pressions amicales pour le faire évoluer (Ajax notamment)

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

Salut à toutes et à tous