Ça te permet quand même de voir si tu as un script qui bouffe de la mémoire, ou est trop long à s'éxécuter ou part dans une boucle d'appels infinie.
Non. La plupart du temps on bosse avec une pile logicielle, des configurations, et des environnements totalement différents de ce qui va tourner en prod. Penser que tu vas trouver quoi que ce soit de non trivial en bridant grossièrement les devs est plutôt une utopie.
Pour te dire, quand tu bosses tu utilises souvent un OS différent de la prod, avec un serveur non supporté, avec une db non supportée, avec un browser non supporté, avec une config de l'appli, du serveur et des libs 100% différentes de la prod, avec des libs backend et frontend en debug, avec des ressources servies par des gros hack et le tout sans latence, en utilisant une seule page, avec un jeu de donnée ridicule, et en ayant tout hacké pour développer efficacement ton objectif en cours. Bref essayer de tirer une conclusion de ce que tu observes sur ton poste de travail en sachant qu'il est impossible d'extrapoler le comportement en situation réelle c'est perdre son temps.
Ce genre de problèmes ça se réfléchi au moment de la conception et de l'implémentation et ça se valide en déployant et testant en condition déterminées. La façon de faire peut énormément varier selon le type de projet, la méthodologie et l'organisation des équipes.
Après le web c'est plein de branle couilles, de PHP warriors et de serial cut&pasters. Mais c'est pas en leur foutant une machine pourrie que tu vas en faire des bons ingénieurs…
[^] # Re: Chaudière à uranium et caféine
Posté par ckyl . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 8.
Non. La plupart du temps on bosse avec une pile logicielle, des configurations, et des environnements totalement différents de ce qui va tourner en prod. Penser que tu vas trouver quoi que ce soit de non trivial en bridant grossièrement les devs est plutôt une utopie.
Pour te dire, quand tu bosses tu utilises souvent un OS différent de la prod, avec un serveur non supporté, avec une db non supportée, avec un browser non supporté, avec une config de l'appli, du serveur et des libs 100% différentes de la prod, avec des libs backend et frontend en debug, avec des ressources servies par des gros hack et le tout sans latence, en utilisant une seule page, avec un jeu de donnée ridicule, et en ayant tout hacké pour développer efficacement ton objectif en cours. Bref essayer de tirer une conclusion de ce que tu observes sur ton poste de travail en sachant qu'il est impossible d'extrapoler le comportement en situation réelle c'est perdre son temps.
Ce genre de problèmes ça se réfléchi au moment de la conception et de l'implémentation et ça se valide en déployant et testant en condition déterminées. La façon de faire peut énormément varier selon le type de projet, la méthodologie et l'organisation des équipes.
Après le web c'est plein de branle couilles, de PHP warriors et de serial cut&pasters. Mais c'est pas en leur foutant une machine pourrie que tu vas en faire des bons ingénieurs…