Discussion :

[PouetX3]

J'aime bien le passage sur "Les erreurs d’orthographe dans vos codes" avec la citation "De plus elles (erreurs) peuvent être difficile à repérer"... Il ne manquerait pas un "s" à "difficile" ?
Sinon, je suis assez d'accord avec ce point... Quand on lit des "BuisnessException" ça fait marrer... Ou alors des fautes de frappe dans les noms de fonction, genre "udpate"...
Alors oui, certains diront que ça n'a pas d'impact sur le code... sauf si on fait des appels dynamiques (DLL, Java, ...)

[tontonnux]

Ou alors des fautes de frappe dans les noms de fonction, genre "udpate"...

C'est ce que j'appelle la "dyslexie claviaire". Mon pire ennemi des jours de fatigue !

[Saverok]

Je suis partiellement d'accord avec toi. Oui l'optimisation est importante (je dirais plutôt que ce qui est surtout important c'est de ne pas faire du code hyper gourmand déjà à la base avant de penser à optimiser). Mais en l'occurrence là c'est le contexte qui veut ça, l'optimisation n'est pas un + dans les jeux vidéos, c'est une propriété importante, voire essentielle.
Tandis que sur un intranet, un back-office ou je ne sais quelle application web non sensible, l'optimisation n'est pas primordiale, l'important c'est que l'application soit fonctionnelle, maintenable et évolutive. L'optimisation trop tôt dans ce genre de contexte, peut être en effet un ennemi et une perte de temps injustifiée.

Je suis partiellement d'accord.
Les temps de réponse d'un application font parti de son ergonomie
Un back office optimisé permet de faire gagner beaucoup de temps.
Par exemple, je travaille dans le eCommerce et le service client utilise beaucoup le back office de la plateforme et il n'est pas envisageable que l'opérateur attende 2min avec le client au téléphone pour que son écran s'affiche

Je pense qu'il ne faut pas revenir inutilement sur son code pour l'optimiser.
Mais au contraire bien penser sa conception et son code pour qu'il soit optimisé dès son écriture primaire.
Cela implique de bien connaître son langage dans la gestion de sa mémoire (par exemple, en java, utiliser des "small" plutôt que des "int" quand cela est nécessaire, des StringBuffer plutôt que des String, etc.)
De même, bien écrire dès le départ ses requêtes SQL : étudier si un index est nécessaire, utiliser l'analyseur de requêtes, etc.
Bref, se poser avant d'écrire le code.

Quels sont les mauvaises habitudes que vous pouvez rajouter à cette liste ?

Ecrire son code d'un jet sans faire de conception

Un développeur peut se passer d'une souris (et tout faire au clavier) mais une feuille et un stylo restent indispensables

[FCDB]

Pour l'indentation, il y a Python.

N°0: ne pas écrire de tests.
N°1: écrire les tests après.

puis le reste.

[Glutinus]

Quelques remarques :

6.
De mon expérience de développeur Business Intelligence et en particulier ETL, j'ai travaillé sur des développements dont les chaînes traitent des millions de lignes base de données et qui doivent passer en quelques heures durant la nuit.
Réfléchir à l'avance sur l'optimisation du temps, c'est indirectement réfléchir sur la manière dont les données sont traitées et toute la logique qui va en amont. En clair si tu sais que ce traitement est risqué, tu réfléchis en réalité sur plusieurs aspects de projet et on met le doigt sur pas mal de problématiques dans les règles de calcul, les processus et ainsi de suite.
Mais après c'est peut-être assez spécifique, je ne le connais pas dans "le vrai code".

Inversement du code - SQL en l'occurrence - qui a généré des gros problèmes de performance est en fait un code qui n'est pas bon
1. n'est pas bon d'un point de vue métier (données incohérentes)
2. n'est pas bon d'un point de vue fonctionnel (données erronées, je fais une différence sur ces deux points)
3. n'est pas bon d'un point de vue architecture (espace et "logistique" mémoire mal géré)
4. n'est pas bon d'un point de vue processus (pas mal de redondance et des difficultés pour a/ relire et débugger b/ réexécuter pour rattraper)

C'était un code qui était particulièrement mauvais mais qui a été fait en deux temps trois mouvements et mis en prod dans la foulée.

Je pense qu'il faut quand même faire la part des choses, certes on ne peut pas tout optimiser au début mais ce n'est pas l'occasion pour livrer un brouillon qui "juste compile" et qui profite d'une équipe homologation débordée pour passer au travers des tests.

8.

Je serai bien content de voir un exemple... car je vois aussi plutôt des contre-exemples !
Parce que c'est sûr que par exemple si sur les cinq développeurs y en a trois qui sont préavis, il vaut mieux ne rien toucher et laisser la magie faire dans trois mois

9.

Mwahaha... comment dire ? Dans un monde idéal y a 99% des gens d'un projet qui serait d'accord.
Y a malheureusement un pourcent qui tient un porte-feuille et qui dit quelque chose comme "Niet!"

[Potomac]

peut-être une mauvaise pratique à ajouter, mais c'est à débattre :

- utiliser le français pour les commentaires et les noms de fonctions et de variables

sur quelques boites où j'ai travaillé la mode était plutôt à adopter l'anglais pour les commentaires dans le code, les noms de variables et de fonctions, donc pas de français, ceci dans l'idée où le code source serait un jour amené à être travaillé par un développeur étranger, l'anglais servant de langue de travail internationale, utile aussi au cas où le code source passerait en open source sur des outils de travail collaboratif sur internet,

ça permet aussi d'obliger le développeur à avoir un minimum de niveau en anglais,

personnellement j'utilise l'anglais dans mon code source

[Sodium]

Je trouve dommage que tout le monde se foute de l'optimisation. Je test souvent plein de petits jeux sur smartphone, et je trouve catastrophique de voir des jeux qui tournaient sur mon atari 1040, ramer comme c'est pas permis (et ce n'est pas limité au développement indépendant).

C'est très différent dans ce cas-ci. Évidemment qu'il faut optimiser la façon dont un programme gère les ressources de la machine. Par contre, réécrire une boucle de manière illisible pour gagner 0.00000000000000000001 seconde est souvent plus nocif qu'autre chose.

peut-être une mauvaise pratique à ajouter, mais c'est à débattre :
- utiliser le français pour les commentaires et les noms de fonctions et de variables

Déjà du français sans accent, c'est moche, pour moi c'est une raison suffisante pour coder en anglais, même si je suppose que certains langages les tolèrent.

[Potomac]

concernant les boucles le compilateur s'il est bien conçu fait déjà en général une bonne optimisation,

l'optimisation elle est à rechercher dans la bonne utilisation des objets, ne pas abuser des tableaux/collections afin de réduire l'empreinte "mémoire" du logiciel

[Zefling]

peut-être une mauvaise pratique à ajouter, mais c'est à débattre :

- utiliser le français pour les commentaires et les noms de fonctions et de variables

sur quelques boites où j'ai travaillé la mode était plutôt à adopter l'anglais pour les commentaires dans le code, les noms de variables et de fonctions, donc pas de français, ceci dans l'idée où le code source serait un jour amené à être travaillé par un développeur étranger, l'anglais servant de langue de travail internationale, utile aussi au cas où le code source passerait en open source sur des outils de travail collaboratif sur internet,

ça permet aussi d'obliger le développeur à avoir un minimum de niveau en anglais,

personnellement j'utilise l'anglais dans mon code source

Quand ta boîte répond à des problématiques franco-françaises pas exportables et que le code ne deviendra jamais open source, ça peut se discuter. Puis je préfère avoir du français lisible que de l'anglais imbitable écrit par des gens qui ne le maîtrisent pas, surtout quand ce sont des sujets qui sont spécifiques à la France. Pour une boîte qui a des vues à l'international, ça devient une obligation.

[Sylvaner]

Justement les impacts de l'effet d'accumulation se voient surtout une fois que chaque partie tourne. A ce moment là, tu va pouvoir optimiser ce qui pose problème.
Il ne s'agit pas de bannir l'optimisation, mais de ne pas "Optimiser votre code prématurément".

Le but de l'optimisation ne doit pas être d'utiliser le moins de ressources possible, mais de permettre au système cible (un smartphone, un serveur avec n utilisateurs, n serveurs, etc...) de faire tourner l'application sans broncher.

Je réagissais non pas à l'article qui parle d'optimision prématurée, mais au post de sevyc64 qui parlait de l'optimisation en général

Je suis partiellement d'accord avec toi. Oui l'optimisation est importante (je dirais plutôt que ce qui est surtout important c'est de ne pas faire du code hyper gourmand déjà à la base avant de penser à optimiser). Mais en l'occurrence là c'est le contexte qui veut ça, l'optimisation n'est pas un + dans les jeux vidéos, c'est une propriété importante, voire essentielle.
Tandis que sur un intranet, un back-office ou je ne sais quelle application web non sensible, l'optimisation n'est pas primordiale, l'important c'est que l'application soit fonctionnelle, maintenable et évolutive. L'optimisation trop tôt dans ce genre de contexte, peut être en effet un ennemi et une perte de temps injustifiée.

Oui bien sur les besoins sont variables en fonction du projet.
Après les optimisations à apporter vont aussi être "déplacées" dans les requêtes de base de données ou la bande passante (quoi que cette dernière a du être totalement oublié j'ai l'impression).

[sevyc64]

Pour en remettre une couche

Oui l'optimisation a son utilité, mais elle est le mal dans le développement moderne actuel. Pourquoi ?

L'optimisation ne devrait et ne doit intervenir que sur un code terminé, finalisé, figé, un code qui n'évoluera plus et que très rarement. Hors avec les méthodes modernes, et surtout les pratiques actuelles, le code n'est jamais terminé, figé. Même déjà livré au client, le code continue d'évoluer, continue d'être développé. De plus, l'habitude a été prise de réduire les tests au minimum, livrant de fait des codes toujours grandement bogués, qu'il faut en permanence reprendre et corriger (et profitant de l'occasion pour introduire de nouvelles fonctionnalités, non testées, amenant leur lot de bugs, et on repart pour un cycle).
On ne prend plus le temps de figer le code, de le couler dans le marbre. Dans ce processus là, faire de l'optimisation à outrance (et même pas forcément à outrance d'ailleurs), si, certes, elle peut amener une forte amélioration de performance, consomme énormément de temps, et ce, à chaque modification du code, c'est à dire en permanence, pouvant aussi largement compliquer la reprise et l'évolution du code, engendrant des surcout de temps, etc. C'est un cercle vicieux qui, au final, rend largement néfaste l'optimisation.

C'est pour cela que je dis, qu'à l'heure actuelle, avec les habitudes de développement qui existent de nos jours, l'optimisation est le mal.

Alors comment faire ?
Ben comme on fait actuellement dans cette société de (sur)consommation, on compense par le matériel. Le matériel ne coute pas cher, il coute rien fasse au surcout de l'optimisation. 1000€ une machine, c'est une semaine de salaire d'un développeur suffisamment pointu pour faire de l'optimisation. C'est à dire, rien, peanuts, nada, insignifiant, ..........
Alors on préconise en config minimum des machines surpuissantes.

Pourquoi avons nous besoin de Core-I5 ou I7 alors que 90% de notre utilisation quotidienne de l'informatique se suffirait de PIII voire PIV avec des logiciels correctement optimisés.
Mais comment arriver à correctement optimiser nos logiciels alors que l'on fait en sorte de sortir une nouvelle version toutes les 3 semaines, ou un nouvel OS tout les ans (vœux pieux pas encore réalisé dans la durée), là ou ce temps ce qu'il faudrait, voire même est inférieur au temps qu'il faudrait pour optimiser correctement la dite-version ?

On nous parle de méthode de développement réactive, d'évolution continue, de cycle court, etc ... Mais tout ça est, par définition, totalement incompatible avec l'optimisation.
Qui est capable, de nos jours, de développement un logiciel qui gère la totalité d'un module spatial, qui tient dans seulement 4Ko de mémoire, qui, 40 ans après sa mise en service, fonctionne encore sans aucun bug ? Même moi, l'ayant pourtant largement appris à l'école je serais bien incapable, je pense, de le refaire actuellement.

[Gugelhupf]

L'idée la plus judicieuse ici serait non pas de chiffrer chaque donnée pour la transporter, mais plutôt de chiffrer directement le média, la canal de transport. Par exemple, on ne chiffrera pas le mot de passe d'un formulaire d'identification avant de le renvoyer au serveur, mais on mettra plutôt directement le formulaire sous une connexion chiffrée via https par exemple.

Merci @miky55 @sevyc64

Je n'avais pas pensé au protocole HTTPS (HTTP + SSL/TLS). Maintenant le souci c'est d'avoir une certification auprès d'une autorité (cela coûte cher dans le cadre non-professionnel).

[blbird]

Règle 3 : ne pas modulariser son code??

On croit rêver de voir encore de nos jours un conseil pareil. Allez, réinventons la roue à chaque fois qu'on développe, et pour tout petit paramètre qui change, réécrivons tout le code.

[GeoffreyOnRails]

- Dans un monde de développeur idéal, les tests ne sont pas assurés par le développeur, ni même d'ailleurs écrit, mais par une équipe indépendante du projet et dédié à ces tests. Mais bon, ça aussi c'est très rare. Et puis c'est bien connu, les tests, c'est une perte de temps et puis il n'y a pas mieux placé que le client en production pour faire les vrais tests

Je ne suis pas d'accord avec cette remarque. Pour moi le développeur ne se contente pas de livrer un bouton sur un écran ou de pisser du code à la chaîne, il livre une solution pour répondre à un besoin client de manière fiable, efficace et maintenable. Les tests sont un outil pour rendre son code fiable, c'est donc pleinement de son ressort.
Quand bien même une équipe externe ferait des tests pour auditer le code (ou même un client pour spécifier une partie de son besoin, on peut toujours rêver ), le développeur devrait toujours avoir à coder quelques tests pour s'assurer du comportement de ce qu'il a écrit (sous-fonctions, cas exotiques pas prévus initialement...).

Règle 3 : ne pas modulariser son code??
On croit rêver de voir encore de nos jours un conseil pareil. Allez, réinventons la roue à chaque fois qu'on développe, et pour tout petit paramètre qui change, réécrivons tout le code.

Justement, ce n'est pas une règle mais une mauvaise pratique à éviter. Et malheureusement, bien modulariser son code et adopter un découpage pertinent n'est pas toujours si facile.

[Saverok]

@GeoffreyOnRails : je suis d'accord avec toi et je dirai même que l'idéal et que les développeurs tournent dans les équipes : conception / dev / test / production

L'écriture des dossiers de conception (ou spécification technique) est un travail complexe car il implique de comprendre le besoin métier et de l'exprimer techniquement en vision macro
Le développement est la construction du programme en concret d'une vision macro. Il y a donc toujours des cas particuliers non prévus (cas métiers ou techniques)
La validation d'un développement est ardu car il faut savoir se mettre à la place des utilisateurs et prévoir tous les cas tordus.
La production a les contraintes du maintient de service et de l'analyse à chaud des anomalies

Ces 4 domaines sont tous des faces d'une seule et même pièce : le métier d'analyste développeur

Le développeur n'est pas juste un ouvrier qui "pisse" des lignes de code à longueur de journée
Un développeur a vocation à coder des programmes qui fonctionnent, qui répondent à un besoin et qui sont utilisés et utilisables

Coder quelques choses que le client ne veut pas ou n'a pas besoin, ne sert à rien
Coder quelque chose qui plante tout le temps ne sert à rien

L'idéal est que chaque membre tourne dans chaque équipe afin de prendre conscience des spécifiés de chaque phase de projet.
J'ai eu l'occasion de le faire et cela a été l'une de mes plus belle expérience professionnelle.

[ypelissier]

Bonjour,
C'est bien de donner des leçons mais il faut aussi accepter l'erreur... Exemple, et je site :
"1 - Les erreurs d’orthographe dans vos codes..."
"5 - Ne pas utiliser un bon chiffrement pour protéger les données : les données critiques doivent être chiffrées parce qu’elles se déplacent sur le réseau et son donc potentiellement exposées à des interceptions chemin faisant."

Ca sonne bien à l'oreille mais ce n'est pas le bon son car elles sont plusieurs...

Sinon, article intéressant mais qui ne peux réellement être mis en pratique que de façon personnelle, à moins de mettre en place de la revue de code, ce qui coûte du temps, de l'argent, une autre ressource (pas forcément à temps plein).

Personnellement je m'applique à le faire depuis des années...

Au plaisir

[tomlev]

C'est bien de donner des leçons mais il faut aussi accepter l'erreur... Exemple, et je site :

No comment

[Kalishah]

peut-être une mauvaise pratique à ajouter, mais c'est à débattre :

- utiliser le français pour les commentaires et les noms de fonctions et de variables

sur quelques boites où j'ai travaillé la mode était plutôt à adopter l'anglais pour les commentaires dans le code, les noms de variables et de fonctions, donc pas de français, ceci dans l'idée où le code source serait un jour amené à être travaillé par un développeur étranger, l'anglais servant de langue de travail internationale, utile aussi au cas où le code source passerait en open source sur des outils de travail collaboratif sur internet,

ça permet aussi d'obliger le développeur à avoir un minimum de niveau en anglais,

personnellement j'utilise l'anglais dans mon code source

Point de vue que je partage. Pour les raisons citées, mais aussi parce que je trouve le français trop verbeux pour l'utiliser dans des noms de variables, fonctions, classes... Sans oublier le problèmes des accents. (Ça passe dans certains langages, comme le C#, mais c'est plutôt l'exception que la règle.) De toute façon, les mots-clés, les fonctions standards, les frameworks, les bibliothèques diverses et variées qu'on est amené à utiliser, eh bien c'est en général de l'anglais ! Rajouter du français au dessus de tout ça, ça fait gloubiboulga. Ça n'interdit pas que le programme puisse être opérationnel, mais on ne peut s'empêcher d'avoir un à-priori négatif. Les commentaires en français, ok, si on est sûr que ça restera franco-français, mais pas le code. Et enfin, il est rare qu'on ait à coder une application en partant d'une page blanche. (Dans mon cas en tout cas.) Or généralement, ce qu'on utilise est en anglais.

Au delà du français, il est de bon sens aussi d'avoir des conventions de nommage suffisamment précises et qu'il faut respecter. Si c'est un petit programme à soi et qui n'est pas destiné à évoluer, on s'en fout un peu, c'est vrai, mais dans le cas contraire, ne pas avoir des conventions de nommage claires ou ne pas les respecter... c'est tendre vers quelque chose de bordélique et donc plus difficile à maintenir.

Pour ce qui est des commentaires, c'est une faute de ne pas en mettre (ou pas assez), mais c'est une faute aussi d'en mettre trop. Il ne faut pas commenter des choses évidentes (fréquent chez les débutants), ni penser que des commentaires puissent constituer une documentation technique. (Les deux doivent exister à part entière.)

Autres points que j'ajouterais :

• Ne pas détourner les patterns de leur sens : bien les connaître, utiliser le bon patern dans le bon contexte.
• Ne pas s'éloigner du cahier des charge en se disant "qui peut le plus peut le moins". S'il y a un flou dans les spécifications, il faut se faire préciser les choses. Un programme doit répondre strictement aux besoins exprimés, ni plus ni moins.

Tout cela peut paraître évident et de bon sens. C'est le cas, en effet. Mais c'est comme le code de la route : tout le monde le connait, or il est tellement facile parfois de passer outre les règles, que ce soit par manque de temps ou par paresse. Même parmi les conducteurs chevronnés.

[foetus]

Point de vue que je partage. Pour les raisons citées, mais aussi parce que je trouve le français trop verbeux pour l'utiliser dans des noms de variables, fonctions, classes... Sans oublier le problèmes des accents.

Un gros avantage de l'anglais, c'est le fait que le mot le plus significatif se trouve à droite: http_request (requête HTTP), tmp_file (fichier temporaire), other_input (autre saisie)

[Kalishah]

Tout à fait. Et puis d'ailleurs il y a les acronymes aussi, qu'on est susceptible d'introduire dans le nommage des fonctions, classes, etc. Pour reprendre l'exemple, HTTP, on comprend tout de suite... tandis que PTHT... eh bien ça ne parle à personne ! On aura donc tendance à ne pas écrire de façon rigoureuse en français mais plutôt en franglais. Et quand on a soi-même ses propres acronymes ? En toute logique on les écrit en français, mais du coup cela fait qu'on a tantôt du français, tantôt du franglais... Bref un méli-mélo !