C'est pourtant une mauvaise idée. Les environnements de développement n'ont pas les contraintes de la production, et heureusement.
Les IDE ou les environnements de dév sont souvent lourds, les moteurs de tests bouffent pas mal, et surtout, le framework ou le serveur d'appli qui tourne différencie souvent bien les environnements dév/prod (bon, php je sais pas, mais…:)
Pour RoR par exemple, les classes ne sont pas mises en cache sur le dév. Ça évite de redémarrer le serveur à chaque modif d'un fichier. Le gestionnaire de resource statiques (l'asset pipeline) est activé en dév et pas en prod (où les .js et .css doivent être pré-générés pour la prod). C'est pratique, mais ça nécessite du CPU. En Java sur les serveurs d'application, il y a le même principe.
Brider le développeur sur son environnement, c'est je pense l'emmerder un peu trop alors qu'au contraire il devrait pouvoir travailler le plus vite possible. Son but n'est pas de faire des tests de perfs sur son appli (qui ne voudraient de toutes façons rien dire par rapport à la réalité de le prod). Le "on va le faire développer sur une machine lente avec peu de mémoire" pour éviter les bugs en prod, j'y crois pas une seconde.
[^] # Re: Chaudière à uranium et caféine
Posté par hermenegilde . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 3.
C'est pourtant une mauvaise idée. Les environnements de développement n'ont pas les contraintes de la production, et heureusement.
Les IDE ou les environnements de dév sont souvent lourds, les moteurs de tests bouffent pas mal, et surtout, le framework ou le serveur d'appli qui tourne différencie souvent bien les environnements dév/prod (bon, php je sais pas, mais…:)
Pour RoR par exemple, les classes ne sont pas mises en cache sur le dév. Ça évite de redémarrer le serveur à chaque modif d'un fichier. Le gestionnaire de resource statiques (l'asset pipeline) est activé en dév et pas en prod (où les .js et .css doivent être pré-générés pour la prod). C'est pratique, mais ça nécessite du CPU. En Java sur les serveurs d'application, il y a le même principe.
Brider le développeur sur son environnement, c'est je pense l'emmerder un peu trop alors qu'au contraire il devrait pouvoir travailler le plus vite possible. Son but n'est pas de faire des tests de perfs sur son appli (qui ne voudraient de toutes façons rien dire par rapport à la réalité de le prod). Le "on va le faire développer sur une machine lente avec peu de mémoire" pour éviter les bugs en prod, j'y crois pas une seconde.