Les IDE proposent beaucoup de fonctionnalités qui peuvent améliorer la productivité des développeurs mais ils:
inflation des fonctionnalités inutilisées voire inutiles (loi de Pareto 80/20 etc.) qui rend plus difficile la courbe d'apprentissage
souvent très spécialisé pour une configuration donnée, dès qu'on en sort, on en revient à la gadoue (Eclipse/Netbeans/Intellij sont des blagues pour faire du C++) et le "savoir-faire" acquis n'est pas réutilisable.
ont souvent des éditeurs assez pauvres comparés à Emacs/Vim
chacun a un workflow personnel différent, ça explique les guéguerres Emacs/Vim, Eclipse/Intellij etc., c'est illusoire de vouloir fournir un IDE pré-configuré pour tous. On ne fait que planter des bâtons dans les roues des gens.
Le plus important, c'est:
d'automatiser au maximum les tâches chiantes pour le développeur
de réutiliser le "savoir-faire" acquis
L'avantage du NoIDE, c'est qu'une fois que tu as maitrisé ton environnement de base, il est adapté à ton workflow personnel (pas ou peu de gâchis), complètement maitrisé (qui maitrise 100% de son IDE ?) et s'adapte rapidement à un changement de contexte.
Je ne dis pas que les IDE c'est inutile, juste que ça n'est pas la panacée, dans certains cas, il y a un réel gain de productivité (Eclipse pour faire du Java, QtCreator pour du Qt etc.). Tout ça pour te dire que non, ça n'est pas une compétence indispensable (je préfère un bon développeur bien outillé qu'un développeur médiocre + super IDE), ça peut figurer sur le CV si ça a un rapport avec le poste.
Personnellement, je n'impose aucun environnement de développement, les seules règles étant:
* coding standard <= à respecter strictement (chacun configure son environnement pour, j'ai fait des confs emacs et vim basiques pour démarrer)
* pas des fichiers liés à un IDE dans le SCM <= ils sont souvent réécrits par ceux-ci et polluent l'historique
* revue de code systématique
* auto-régulation dans le nombre de langages, frameworks par projet et au niveau de l'équipe (formule empirique: chienlit = nb de pers * tps d'apprentissage * exp(nb changements de contexte))
Je suis sensé travailler avec des ingénieurs, je ne devrais pas avoir à décider de leur environnement de travail, à eux de s'organiser pour arriver à un résultat professionnel et de collaborer avec les autres.
# Non, mais ...
Posté par GeneralZod . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 10.
Les IDE proposent beaucoup de fonctionnalités qui peuvent améliorer la productivité des développeurs mais ils:
inflation des fonctionnalités inutilisées voire inutiles (loi de Pareto 80/20 etc.) qui rend plus difficile la courbe d'apprentissage
souvent très spécialisé pour une configuration donnée, dès qu'on en sort, on en revient à la gadoue (Eclipse/Netbeans/Intellij sont des blagues pour faire du C++) et le "savoir-faire" acquis n'est pas réutilisable.
ont souvent des éditeurs assez pauvres comparés à Emacs/Vim
chacun a un workflow personnel différent, ça explique les guéguerres Emacs/Vim, Eclipse/Intellij etc., c'est illusoire de vouloir fournir un IDE pré-configuré pour tous. On ne fait que planter des bâtons dans les roues des gens.
Le plus important, c'est:
d'automatiser au maximum les tâches chiantes pour le développeur
de réutiliser le "savoir-faire" acquis
L'avantage du NoIDE, c'est qu'une fois que tu as maitrisé ton environnement de base, il est adapté à ton workflow personnel (pas ou peu de gâchis), complètement maitrisé (qui maitrise 100% de son IDE ?) et s'adapte rapidement à un changement de contexte.
Je ne dis pas que les IDE c'est inutile, juste que ça n'est pas la panacée, dans certains cas, il y a un réel gain de productivité (Eclipse pour faire du Java, QtCreator pour du Qt etc.). Tout ça pour te dire que non, ça n'est pas une compétence indispensable (je préfère un bon développeur bien outillé qu'un développeur médiocre + super IDE), ça peut figurer sur le CV si ça a un rapport avec le poste.
Personnellement, je n'impose aucun environnement de développement, les seules règles étant:
* coding standard <= à respecter strictement (chacun configure son environnement pour, j'ai fait des confs emacs et vim basiques pour démarrer)
* pas des fichiers liés à un IDE dans le SCM <= ils sont souvent réécrits par ceux-ci et polluent l'historique
* revue de code systématique
* auto-régulation dans le nombre de langages, frameworks par projet et au niveau de l'équipe (formule empirique: chienlit = nb de pers * tps d'apprentissage * exp(nb changements de contexte))
Je suis sensé travailler avec des ingénieurs, je ne devrais pas avoir à décider de leur environnement de travail, à eux de s'organiser pour arriver à un résultat professionnel et de collaborer avec les autres.