Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
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, ...)
C'est ce que j'appelle la "dyslexie claviaire". Mon pire ennemi des jours de fatigue !Envoyé par PouetX3
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.
Ecrire son code d'un jet sans faire de conceptionQuels sont les mauvaises habitudes que vous pouvez rajouter à cette liste ?
Un développeur peut se passer d'une souris (et tout faire au clavier) mais une feuille et un stylo restent indispensables
Pour l'indentation, il y a Python.
N°0: ne pas écrire de tests.
N°1: écrire les tests après.
puis le reste.
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!"
- So.... what exactly is preventing us from doing this?
- Geometry.
- Just ignore it !!
****
"The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
***
Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019
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
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.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).
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.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
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
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.
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
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).
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.
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).
N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java
Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ?Contacter Gokan EKINCI
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.
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.- 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
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...).
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.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 : 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.
Ne pas faire de fautes en en laissant une trainer dans l'article...
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
No comment
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
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.
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)
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 !
Répondre avec citation
Partager