Discussion :

[DonQuiche]

pour le pair programming, il existe de la littérature qui mesure les couts, mais aussi les bénéfices.

J'adore : tu es la seule personne ici à fournir un lien vers une étude compilant diverses sources empiriques plutôt qu'une opinion et tu te manges un score de -1 !

L'important sur les réseaux sociaux, c'est de brosser dans le sens du poil. Prière de ne pas sortir du cadre.

[bountykiler]

C'est quelque chose que l'on voit de plus en plus (il me semble), à savoir remettre en cause tout un ensemble de pratiques que beaucoup de personnes considèrent comme étant "meilleures". Et j'avoue que cette remise en question n'est pas une mauvaise chose en soi.
Je pense que c'est aussi une question de personnalité. Certains vont directement chercher à appliquer le dernier truc à la mode alors que d'autres (comme moi) vont prendre tout cela avec plus de recul. Puis c'est vrai qu'en fonction des personnes, du type de projet et probablement d'autres facteurs ces techniques se révèleront être plus ou moins efficace.

- Le TDD : c'est sur si on laisse pas le temps au développeur de faire les choses, ça va échouer ! ( ou pire on choisit un dev qui ne sait et ne veut pas savoir ce que c'est qu'un test unitaire)
- Dans beaucoup d'équipes hétérogènes certaines personnes ne savent même pas ce que c'est , et il n'y a souvent pas d'architecte.

Tiens, perso je suis assez anti-TDD. Pas pour les raisons que tu cites, mais parce que le fait de faire du TDD a tendance à avoir un impact sur le code que l'on va écrire, en ce sens que l'on voudra rendre celui-ci testable. Cela a comme conséquence de rendre le code plus complexe que nécessaire (souvent via l'ajout d'interfaces qui n'ont de sens que dans le contexte du TDD), le rendant du coup plus difficile à maintenir.

- Le développement par pair : si le binôme n'est pas bon ou ne s'entend pas c'est l'échec. Par contre si il s’entendent, ça peut donner de superbes résultats.

Bof. Pour ce que j'en ai pratiqué, cela ne c'est jamais avéré productif. Je sais que beaucoup de personnes ne seront pas d'accord avec moi, mais je vais toujours plus vite quand je travaille seul, sans avoir quelqu'un d'autre à qui je dois expliquer ce que je fais, pourquoi, comment je compte m'y prendre,... Par contre cela peut avoir de l'intéret quand in a une personne + expérimentée qui explique ce qu'elle fait à qqun d'autre.

- L'agile est souvent du faux agile (XP avec 6 intermédiaires avant le métier, faut pas s'étonner que ça échoue )

Ca sent le vécu .
Et là dessus je te dirai que je que assez d'accord avec toi. Bien souvent, les supérieurs hiérarchiques demandent que l'on travaille de manière agile parce que c'est + mieux, mais ne comprennent en rien ce que cela signifie et/ou implique.

Bref les managers ne pensent souvent qu'en terme de coût (je simplifie avec une pincée de mauvaise fois ) .

Elle est ou la mauvaise fois? C'est juste un fait. Les managers ne pensent qu'en terme de cout et de revenus sans rien comprendre au reste, ce qui abouti en effet souvent à une mauvaise gestion. (en tout cas, cela a été comme cela dans la grande majorité des boites pour lesquelles j'ai déjà travaillé.)

Sinon, pour continuer la liste:
- L’intégration continue
Quasi présent partout ou je suis passé, cela a touours apporté un plus et je n'ai pas d'exemple ou cela a été contre-productif.
- Les design patterns
Oui et non. Attention à bien les appliquer judicieusement, et ne pas chercher à mettre des design pattern pour mettre des design pattern. (j'ai déjà vu cela).
- Le code review
On en fait dans la boite ou je suis actuellement, et cela apporte un plus indéniable.
- Certains ont parlé des conventions d'écriture de code.
Sans vouloir entrer dans un débat sur ce sujet (ce serait bien trop long), il en est une qui est des plus basiques et qui est systématiquement non-respectée par nombre de programmeurs : faites des méthodes courtes!!! Trop souvent, je vois des méthodes qui font plus de 300 lignes de code, ont plusieurs niveaux d'imbrications (4 voir plus), ou contiennent une grande part de code dupliqué. C'est bien là quelque chose que je ne comprendrai jamais...

[dfiad77pro]

Bof. Pour ce que j'en ai pratiqué, cela ne c'est jamais avéré productif. Je sais que beaucoup de personnes ne seront pas d'accord avec moi, mais je vais toujours plus vite quand je travaille seul, sans avoir quelqu'un d'autre à qui je dois expliquer ce que je fais, pourquoi, comment je compte m'y prendre,... Par contre cela peut avoir de l'intéret quand in a une personne + expérimentée qui explique ce qu'elle fait à qqun d'autre.

Justement d'ou l'intérêt de bien s'entendre et de savoir répartir les tâches, ça dépends aussi du contexte ( nouveau projet, etc).
Moi aussi je travail plus vite seul si le domaine est trop ciblé

L'intérêt lorsque qu'une personne est plus expérimenté, c'est que cela fait de la formation et de la répartition de connaissance
*


pour les conventions d'écriture de code, je me méfie, beaucoup d'entreprises , par exemple basés sur un SI Oracle ( ou autres) prennent des conventions de nommage oracle pour le java ça donne des méthodes du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7

public void PKG_XY_MAJ_TABLE_T(30 paramétres){

// Code d'accès à la procédure

}

et c'est pas une blague, je l'ai notamment vu dans une énorme structure sur l'ensemble des logiciels ...

[yahiko]

Bonnes pratiques ou pas, à un moment donné

[Laurent 1973]

Tiens, perso je suis assez anti-TDD. Pas pour les raisons que tu cites, mais parce que le fait de faire du TDD a tendance à avoir un impact sur le code que l'on va écrire, en ce sens que l'on voudra rendre celui-ci testable. Cela a comme conséquence de rendre le code plus complexe que nécessaire (souvent via l'ajout d'interfaces qui n'ont de sens que dans le contexte du TDD), le rendant du coup plus difficile à maintenir.

J'ai l'impression que tu confonds de notion.
Le TDD: Test Driven Developpement - dont l'idée première est d'écrire un test simple avant de développer.
Les Tests Unitaires en isolation: pratique qui veux tester chaque couche une par une en s'isolant de l'aval et l'amont via des versions Fakes les simulant.

Donc ce serait plus de l'anti-Tests Unitaires en isolation que tu serais au vu de ton explication.

Je voudrais te posé une question simple: Comment réalise tu des tests unitaires si tu n'as pas la possibilité d'isolé facilement chaque couche?
Tu n'en fais peut-être pas, et tu réalises seulement des tests integrations/fonctionnelles.
Tu dois avoir alors pas mal de la complication pour réaliser des tests métiers en te trainant des couches persistantes (fichiers, BD, ...) difficile et lourde à configurer.
Et dans ce cas là, quant un test échoue suite à des améliorations/corrections, il est beaucoup plus dure de déterminer quel couche a provoqué la régression.
Ne valider un logiciel que par des tests fonctionnelles peut conduire aussi à un manque de couverture de tests (surtout au limite) et donc d'augmenter les tickets de support.

En faite, ces "interfaces" qui apparaissent via les besoins du Test Unitaire, je les trouves au contraire utile pour une compréhension "black-box" de chaque couche.
En effet, si on documente l'API de ces interfaces (via du doxygene par exemple), lorsque on doit réaliser des modifications amonts ou avales à cette couche, on a pas à aller voir systématiquement le code de cette partie.
Et de plus chaque couche à un rôle bien défini qui donne une architecture plus propre (enfin c'est mon avis)

En plus, et cela m'est arrivé, si pour les besoins d'une évolution en maintenance, on a besoin de refaire entièrement une couche: l'isolation déjà intégrer dans cette architecture le rend plus facile combiner à des tests de comportement déjà prêt.

Bof. Pour ce que j'en ai pratiqué, cela ne c'est jamais avéré productif. Je sais que beaucoup de personnes ne seront pas d'accord avec moi, mais je vais toujours plus vite quand je travaille seul, sans avoir quelqu'un d'autre à qui je dois expliquer ce que je fais, pourquoi, comment je compte m'y prendre,... Par contre cela peut avoir de l'intéret quand in a une personne + expérimentée qui explique ce qu'elle fait à qqun d'autre.

Là c'est toute la notion de travail en équipe.
Depuis que je travail dans l'informatique, j'ai toujours été amené à partager mon code avec mon collègue.
De travailler sur du code sensible à deux (j'avoue que je ne pratique pas le pair programming systématiquement) permet déjà de partager les idées et les connaissances sur ce code.
Mais aussi, le co-pilote est là pour relire à mesure ce que le pilote tape: toutes les "bonnes" pratiques que l'équipe s'en engager à respecter sont plus assuré à deux que tout seul.

Ce n'est pas une pratique à réserver pour un couple novice+expert.
Deux experts au contraire ont de l’intérêt de travailler ainsi.
Déjà, le pilote n'a pas besoin d'expliqué ce qu'il fait, l'autre comprend en générale assez vite où le premier veux en venir.
Et puis justement, c'est l'occasion d'échanger de façon bref les idées (ex: "On met en place MVC, ok?" - "Tu pense pas que le pattern Observer n'est pas plus adéquat?")
Les experts vont échangé sur le fond des idées, afin justement de confronté leurs idées et de faire émerger le meilleur algorithme possible tout en respectant du premier coup des bonnes pratiques.

Mais sinon je te suis totalement sur ta remarque sur le manque d'implication de la hiérarchiques sur l'organisation concrète des équipes.
Et ils ne raisonnent qu'à cours terme, rarement sur du moyen et long terme.

+1 sur les longueurs de méthodes.
C'est aussi pour cela que j'utilise des outils d'analyses statiques de code (comme lint en c++)
Ces outils mettre en avant les méthodes, les classes, et les fichiers trop long.
Ils calculent souvent aussi la complexité cyclomatique (nombre chemin possible dans une fonction) limitant aussi les nombres d'imbrication de condition et boucle.

[sdevilcry]

Sa dépend du langage je dirais, prend le c:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for (i=1; i<6; i++) {
 printf("%d", i);

}

C'est beau 255 caractère dans une variable , je reconnais je suis de mauvaise foi.
Dans mon premier exemple, tu peut remplacer 6 par un nom explicite, mais je vois l’intérêt de remplacer i par autre chose ?

Beaucoup de mauvaise foi en effet
Crois moi ton "i" tu peux l'appeler simplement currentQuelQuelChoseExplicit ce que je fais tout le temps et c'est plus agréable à la lecture.

Typiquement et un exemple parmi tant d'autre et peu importe le langage :
Avec des objects :
myObjectsList = [0 => object1, 1 => object2, ...]; foreach (myObjectsList as currentObject => object)
Ou des tableaux :
myArraysList = [0 => array1, 1 => array2, ...]; foreach (myArraysList as currentArray => arrayInfo)
(Vous pouvez remplacer le foreach par un for hein c'est juste pour faire un exemple ou le besoin d'utiliser l'index est présent).

Et la quand je lis le code je sais ce que ça fait etc etc. Après c'est peu être subjectif ?

[RyzenOC]

(Vous pouvez remplacer le foreach par un for hein c'est juste pour faire un exemple ou le besoin d'utiliser l'index est présent).

Je suis clairement pas d'accord, un foreach n'a rien na voir avec un for, quand je fais un foreach je ne mets jamais de i ou de j, je mets des variables explicites.

Je mets des i et des j uniquement dans des "for" et des "while"

[Laurent 1973]

Je trouve interessant sazearte que tu ne code pas un "foreach" ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

foreach(myObjectsList as i => object)

mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

foreach(myObjectsList as currentObject => object)

et que pour un "for" tu fasses:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(i=0;i<myObjectsList.length();i++)

mais surtout pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(currentObject=0;currentObject<myObjectsList.length();currentObject++)

Tes conventions de nommage sont amusantes
Enfin, chacun sa logique.

[RyzenOC]

Un for c'est une itération du code que je répète n fois, donc remplacer i par mavaraible me semble inutile.
Le foreach sert à boucler sur tous les éléments d'un tableau ou d'un objet, voila comment je fais mes foreach:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
foreach ($tab as &$valeur_de_mon_tableau) {
    $valeur_de_mon_tableau = ; //quelquechose...
}

avec un pointeur pour économiser de la puissance de calcule.

Ici $valeur_de_mon_tableau ne contient pas un nombre compris entre 0 et quelque chose, mais une donnée "importante".

[mactwist69]

Pour moi l'utilisation du terme "Meilleur pratique" est dangereuse car elle sous-entends que la méthode suffit à elle même pour faire un bon programme.

Or pour moi tous ces outils peuvent être utiles (si on a le temps et donc l'argent) si et seulement si les bases des VRAIES bonnes pratiques sont en places.


Une expérience que j'ai eu avec la fameuse méthode Agile. Cette méthode à été adoptée comme méthode de développement d'un gros projet.

Or dans ce gros projet, le travail d'analyse a été largement bâclé (Pour moi c'est la la VRAI bonne pratique qui a été complètement zappée et qui rends caduc toute les fausses bonnes pratiques).

Parce que du coup, les développements se sont fait au fur et à mesure, le modèle a été mis à jour petit à petit en fonction des besoins. Et comme il faut fournir des livrables souvent il y avait forcement beaucoup de retours en arrières, des ajouts sauvages, des modifications du modèle non réfléchis avec beaucoup d'impacts etc...

La tenu de réunions très rapprochés a été en fait l'excuse pour s'autoriser à ne pas écrire de cahier des charges et créer "à la volée" les modules un par un sans vision globale au nom de la réactivité.

Donc au final, la méthode agile, présentée comme LA bonne méthode, a été utilisée comme méthode principal de développement et a été dans ce cas là désastreuse.

Si on s'appliquait déjà à développer des projets correctement, en respectant les vraies normes, alors oui, les "méthodètes" à l'américaine pour avancer en équipe et être réactif peut aider, mais attention à ne pas aller à la facilité.

[bountykiler]

Je voudrais te posé une question simple: Comment réalise tu des tests unitaires si tu n'as pas la possibilité d'isolé facilement chaque couche?
Tu n'en fais peut-être pas, et tu réalises seulement des tests integrations/fonctionnelles.
Tu dois avoir alors pas mal de la complication pour réaliser des tests métiers en te trainant des couches persistantes (fichiers, BD, ...) difficile et lourde à configurer.
Et dans ce cas là, quant un test échoue suite à des améliorations/corrections, il est beaucoup plus dure de déterminer quel couche a provoqué la régression.
Ne valider un logiciel que par des tests fonctionnelles peut conduire aussi à un manque de couverture de tests (surtout au limite) et donc d'augmenter les tickets de support.

En faite, ces "interfaces" qui apparaissent via les besoins du Test Unitaire, je les trouves au contraire utile pour une compréhension "black-box" de chaque couche.
En effet, si on documente l'API de ces interfaces (via du doxygene par exemple), lorsque on doit réaliser des modifications amonts ou avales à cette couche, on a pas à aller voir systématiquement le code de cette partie.
Et de plus chaque couche à un rôle bien défini qui donne une architecture plus propre (enfin c'est mon avis)

J'ai l'impression que pour toi le fait de faire des tests unitaires et le fait de découper son applications en différentes couches sont liés. Sache qu'il n'en est rien! Ce n'est pas parce que je ne prends pas en compte la testabilité de mon application lors du dev que je ne la découpe pas en différentes couches. Au contraire, ce découpage est quelque chose d'essentiel si je veux etre en mesure de maintenir mon application efficacement, aussi je le fait non pas pour que mon application soit testable mais pour qu'elle soit maintenable (et aussi pour que certaines parties soient réutilisables ailleurs).
Après, pour ce qui est des couches persistantes comme tu les appelles, je ne les trouve pas lourde à configurer du tout. Ce qui me prends le plus de temps c'est plutot de faire en sorte que ma db ou mes fichiers contiennent bien les infos correspondant à mon cas de test, cela étant fortement lié à la complexité du test que je veux effectuer. Maintenant, il est vrai que lors de mes tests je m'autorise à accéder directement à des fichiers et/ou à une base de données, chose que des puristes ne tolèreraient pas.

Là c'est toute la notion de travail en équipe.
Depuis que je travail dans l'informatique, j'ai toujours été amené à partager mon code avec mon collègue.
De travailler sur du code sensible à deux (j'avoue que je ne pratique pas le pair programming systématiquement) permet déjà de partager les idées et les connaissances sur ce code.
Mais aussi, le co-pilote est là pour relire à mesure ce que le pilote tape: toutes les "bonnes" pratiques que l'équipe s'en engager à respecter sont plus assuré à deux que tout seul.

Ce n'est pas une pratique à réserver pour un couple novice+expert.
Deux experts au contraire ont de l’intérêt de travailler ainsi.
Déjà, le pilote n'a pas besoin d'expliqué ce qu'il fait, l'autre comprend en générale assez vite où le premier veux en venir.
Et puis justement, c'est l'occasion d'échanger de façon bref les idées (ex: "On met en place MVC, ok?" - "Tu pense pas que le pattern Observer n'est pas plus adéquat?")
Les experts vont échangé sur le fond des idées, afin justement de confronté leurs idées et de faire émerger le meilleur algorithme possible tout en respectant du premier coup des bonnes pratiques.

Déjà, pour moi ce n'est pas au moment de coder le projet que l'on doit se poser la question de savoir si on fait du MVC, du MVVM, si on mets des observers ou tout autre pattern en place. Pour moi c'est quelque chose qui doitavoir été réfléchi en amont (et effectivement à plusieurs c'est mieux). Après pour ce qui est du partage des connaissances et les échanges d'idées, je trouve que le code review est au moins aussi efficace à ce niveau, avec le défaut certes il est vrai qu'il faut parfois recommencer une partie du travail suite à une remarques d'un collègue. Par ailleurs je trouve cela un mal pour un bien en ce sens que personne n'aime faire 2 fois le même travail. Du coup, quand un collègue fait des remarques, on a plutot tendance à les prendre en compte et/ou à en débattre, histoire que cela ne se reproduise pas le coup d'après. En un sens, c'est quelque chose qui nous oblige à avancer et à apprendre de nos erreurs.

[Neckara]

et que pour un "for" tu fasses:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(i=0;i<myObjectsList.length();i++)

mais surtout pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(currentObject=0;currentObject<myObjectsList.length();currentObject++)

Tes conventions de nommage sont amusantes
Enfin, chacun sa logique.

Je ne voudrais pas pinailler, mais currentObject a beau être "explicite", il est faux. Ce n'est pas l'objet courant, mais l'index de l'objet courant.

Et encore "objetCourant", cela ne veut rien dire du tout. i est tout aussi explicite.
On est dans une boucle, on a un i, on sait que c'est l'index.

Un nom à rallonge n'est pas forcément explicite, il faut savoir ce qu'on veut donner comme informations supplémentaires.
Si on ne donne aucune information, pourquoi ne pas utiliser i, j, it ?
De plus, pour la même signification le code en sera qu'un peu plus lisible.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
for(int i = 0; i < tab.size()/2 ; ++i)
     tab[i] = i;

Ne me choque pas.
Déjà, parce qu'on a pas besoin d'un nom explicite pour savoir directement ce qu'est i.
Ensuite, parce que i a plusieurs rôles, c'est un index mais aussi une valeur.
Après, si on veut rendre i plus explicite, quelle information souhaitez vous lui rajouter ?

Cela dépend aussi du contexte, si tu manipule des images, r, g, b, a sont très explicites.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for(int r = 0; r < MAX_RED ; ++r)

Il y a aussi w et h pour width, et height, x et y, … quand on manipule des dimensions rect.setDim(uint32_t x,uint32_t y,uint32_t w,uint32_t h)
Après, cela dépend du contexte et il ne faut pas tout mélanger, s'il peut y avoir ambiguïté, mettre alpha au lieu de a sera plus explicite. Mais dans le cas contraire et si on a aucune information à rajouter, a suffit amplement.
Par exemple en nom d'attribut ou en nom de paramètre d'une fonction, cela me semble peu ambiguë, et certaines bibliothèques ne s'en privent pas.

Après, il faut éviter d'inventer ses propres abréviations, autant tout le monde sait que nb c'est number, it, iterator, … autant zvff…

Zèbre Volant Fou Furieux…
Cet exemple peut vous paraître absurde, mais pas plus que certaines abréviations qu'on peut être tenté de créer.
Il faut penser qu'une abréviation créée, cela peut être clair comme de l'eau de roche pour certain et un zvff pour d'autres.

Mais cela peut être acceptable comme pgsql pour posgresql ou db pour database, dbconn pour database connexion.


Chaque domaine/contexte a ses propres abréviations que tout le monde comprend. C'est comme tout, il ne faut pas en abuser.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int w; // c'est quoi w ?? largeur ? poids ?
setDim(uint32_t x,uint32_t y,uint32_t w,uint32_t h); // là tout le monde sait que c'est la largeur.

int r; // c'est quoi ?? rouge ? rayon ?
color.r; // c'est rouge

Pour les maths, c'est la même chose, le but c'est que la formule puisse être lue le plus facilement par quelqu'un du domaine et donc réutiliser leurs conventions.

[pierre_479]

Effectivement si l'on entend par meilleures pratiques celles décrites par E. Dietrich cela peut prêter à confusion. Ces pratiques (et bien les sept mises en avant) relèvent d'avantage d'une méthodologie, d'une façon de faire globale qui s'appliquerait à tout les cas de figures et qui donc garantirait de meilleurs résultats. Mais à part pour certaines (code review, design patterns) cela reste discutable. Et même l'utilisation des design patterns ne s'applique que dans le cas de la programmation objet.
Ensuite d'autres bonnes pratiques existent et relèvent du type de projet et du principal outil utilisé pour le mettre en œuvre. Par exemple si des pratiques sont recommandées par le créateur d'un framework de développement comme étant de bonnes pratiques, elles ont plus de chances de devoir être prises en considération. A mon avis certaines pratiques non citées sont plus intéressantes, comme l'utilisation d'un framework MVC pour créer une séparation fonctionnelle du code (dans un projet de site Web cela est indéniablement efficace, pour peux de comprendre de quoi il s'agit), comme la réduction du nombre de lignes de code dans un but de réutilisation qui permet une meilleure maintenance/évolution des programmes, enfin comme la cohésion qui limite la responsabilité d'une classe en programmation objet. Dernier principe qui évite d'avoir un code mal organisé qui fasse tout et n'importe quoi, surtout n'importe quoi …

[ChristianRoberge]

Toutes les techniques et réflexions sur l'élaboration de "meilleur" code ont du bon. Là où je crois qu'il commence à avoir un sérieux problème est quand une technique en particulier devient un dogme, la seule façon de faire du code ou un projet. C'est une aberration de croire qu'une technique donnée résoudra tous nos problèmes de conception, gestion et codage. Il faut garder ouvert toutes les éléments qui sont successibles de nous aider. Il faut surtout réviser nos procédures et méthodes souvent car l'informatique est en perpétuelle évolution.

[RyzenOC]

Toutes les techniques et réflexions sur l'élaboration de "meilleur" code ont du bon. Là où je crois qu'il commence à avoir un sérieux problème est quand une technique en particulier devient un dogme, la seule façon de faire du code ou un projet. C'est une aberration de croire qu'une technique donnée résoudra tous nos problèmes de conception, gestion et codage. Il faut garder ouvert toutes les éléments qui sont successibles de nous aider. Il faut surtout réviser nos procédures et méthodes souvent car l'informatique est en perpétuelle évolution.

Le plus important selon moi c'est pas les techniques, mais le choix du langage qui vas ensuite influencer sur le reste. Prendre un langage qui n'est pas conçue pour faire le projet, même avec toutes les bonnes techniques du monde c'est très mal parties.
Un truc simple, ont te demande de faire un site web, il vaut mieux le faire en php/python/Perl/Java qu'en C/C++ par exemple (sauf cas très très rare)

[Neckara]

Un truc simple, ont te demande de faire un site web, il vaut mieux le faire en php/python/Perl/Java qu'en C/C++ par exemple (sauf cas très très rare)

Avec une bibliothèque DOM, c'est déjà un peu mieux. Personnellement, je trouve 100x plus propre un code écrit avec DOM, même en C, qu'un code écrit en PHP sans DOM.

Après, c'est vrai que pour faire tout ce qui est session, GET, POST, cela va être un peu plus difficile, mais ce n'est en aucun cas lié au langage mais aux bibliothèques. C'est sûr que faire un site en C++ sans bibliothèque… .
Mais on ne va pas me dire qu'aucun malade n'a jamais crée de bibliothèque pour faire des sites en C++ .

Je ne connais pas très bien les possibilités de Python et de Perl.
À part la simplicité du PHP, personnellement, je n'y vois pas pas d'avantages.
Pour le Java, on a effectivement du JSP, qu'on retrouve aussi en C++ avec CSP (?).

Plus qu'une question de langage, je pense donc que c'est surtout une question de bibliothèques utilisées et/ou existantes.
À par des notions de "plus ouverts aux débutants", je ne sais pas si ces langages ont vraiment intrasèquement des choses significatives qui les avantagent dans la conception de sites.


En revanche, pour le choix du langage, je pense qu'il faut en priorité prendre un des langages utilisé par l'entreprise ou dans l'environnement dans lequel on se trouve. Prendre un langage avec lequel on est familier, à l'aise. Essayer aussi de minimiser le nombre de langages utilisés. Par exemple certaines boîtes utilisent du node.js pour remplacer PHP pour n'avoir plus que du JavaScript côté client et côté serveur.
Sauf contraintes spécifiques bien évidement.

[Laurent 1973]

Un truc simple, ont te demande de faire un site web, il vaut mieux le faire en php/python/Perl/Java qu'en C/C++ par exemple (sauf cas très très rare)

Tout dépend bien sur de ton contexte technologique.

J'ai travaillé sur l'amélioration d'un portail web en c/c++
C'était le cas d'un boitier ARM pour réaliser un petit portail de configuration.
Les ressources limités de la board (mémoire, vitesse CPU) interdisaient un langage de scripting pour avoir des performances acceptables pour un opérateur sans devoir qu'elle stop son rôle premier métier.

Le choix technologique doit être avant tout dicter par les contraintes, les développeurs doivent alors s’adapter.
Tenter d'imposer une technologie sans prendre en compte les contraintes peut s’avérer risqué.

[DonQuiche]

Si j'ai bien tout compris, et dites moi si je suis hors-sujet, mais l'erreur générée en cas d'utilisation sans redémarrage des Boeing tous les 248 jours minimum provient d'un manque de prévoyance ou d'une incapacité pour cause de brevets logiciels à faire mieux ?

Ceci est une pure question informative.

La question est hors-sujet mais je vais y répondre : c'est une erreur très commune.

A priori 32 bits peuvent sembler suffisants pour stocker une durée. En réalité c'est loin d'être suffisant et il faut utiliser des variables sur 64 bits (y compris lorsqu'on travaille en réel, sous peine de voir des problèmes de précision apparaître après quelques temps).

Cela peut être une erreur aussi manifeste, ou bien le programmeur ignorait manipuler une variable aussi petite (utilisation d'une abstraction créée par un autre), ou bien la résolution initiale du timer était différente (le problème ne serait apparu qu'après dix ou cent ans sans redémarrage), ou bien le générateur était supposé être redémarré fréquemment (et peut-être l'était-il il y a trente ans quand ce code avait été écrit), etc.