Yep, tu as certainement raison kirkis. Mais dans ce cas je ne vois pas pourquoi le code était "encodé", peut-être par méconnaissance du précédent développeur ?En règle générale, je suis d'accord avec toi, le client aura certainement une préférence pour la SSII qui lui laisse le contrôle du code. Dans ce cas précis, cependant, je ne pense pas me tromper (mais c'est toujours possible).
Pour rappel, il y a quelques petites différences de mentalité entre l'Espagne et la France...
Ok. C'était pour savoir si on parlait bien de la même chose. Effectivement, ces sites ne peuvent se permettre d'avoir une quelconque "défaillance" comme tu dis.Tout d'abord vous (le vous du pluriel) avez pu constater que j'ai pris certaines précautions de langage, j'ai mis "petits et professionnels" entre guillemets.
Par professionnels j'entends, sites ayant une finalité en laison directe avec une activité professionnelle (vente, gestion, administration, représentation... ) d'un organisme (entreprise, administration, association...).
Ce genre de site aux contraire des sites personnels engagent les organismes qui en sont les maîtres d'ouvrage et les conséquences d'une défaillance possible sont sans commune mesure avec celle d'un site personnel.
Mais de ce coté, j'ai du mal à voir en quoi le fait que le code soit interprété pause réellement problème : PHP necessite effectivement des tests rigoureux du code ; mais de toutes façons n'importe quel développeur conscienceux le fait, peu importe le langage, non ?
Pour les erreurs, comme l'a parfaitement souligné Kirkis, il ne s'agit là que d'une erreur de configuration de PHP : celui ci indique clairement de telles erreurs, mais pas aussi bien qu'un compilateur évidement. Si le code était compilé, cette erreur serait détectée dès la compilation ; actuellement ce n'est pas le cas, il faut que la portion de code incréminée soit exécutée pour se rendre compte d'une telle erreur (s'il s'agit d'une classe, d'une fonction, ou même d'une simple boucle, ce n'est pas forcément évident).
Ouep, on se retrouverait avec des régulateurs de vitesse qui déconnentLes problèmes de rapidité d'exécution sont souvent (pas systématiquement) de faux problèmes par contre ceux concernant la qualité et la maintenabilité sont le pain quotidien des développeurs et font de l'activité de développement une activité encore au stade de l'enfance, imaginez nos voitures, télévisions, ascenseurs ... de la même qualité que celle des applications développées actuellement !
Pour moi c'est surtout le fait qu'il soit "open source", "gratuit" et "accessible" qui donnent une telle étiquette. Et je les en blamme pas : il suffit de regarder le travail de certains sur ce même forum pour prendre peur. Le problème c'est qu'il faudrait arrêter de comparer le code produit par un ado comme passe-temps et celui produit par un développeur de métier.L'absence de compilateur confine souvent PHP (me semble-t-il) aux yeux de beaucoup de "professionnels" au rang de langage de second ordre, alors que sa richesse fonctionnelle ne le situe pas vraiment si loin de ce qu'était Java ne serait-ce qu'il y a 3 ou 4 ans, du temps où J2EE n'était encore qu'une réalité de laboratoire (là je vais me faire flinguer par les buveurs de café Wink).
Répondre avec citation
Envoyé par Kioob
Mais je ne compte pas le nombre de fois ou on m'a dit "non" lorsque je suggérais l'utilisation de PHP pour un projet... "C'est pas pro c'est open source", ça fait toujours mal d'entendre ça, mais comment veux tu raisonner une personne qui en est persuadé ?
C'est pour cette raison que j'ai essuyé des refuts dans mes projets (une fois la question du "mais c'est open-soure !" dépassée)... Maintenant, certaines entreprises ayants les resources et compétances y voient une possibilitée de réactivitée sans précédant car elles peuvent corriger elles-mêmes les problemes 
.
: 
Partager