Discussion :

[foetus]

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 !

Attention il y a les acronymes et les abréviations. En français on est très rigoureux sur les règles typographiques (carrément à mettre des accents sur les majuscules ) et on ajoute des points aux abréviations ce que ne font pas les américains.
On devrait écrire requête H.T.T.P., et on joue à un M.M.O.R.P.G.. (Nathanael de Rincquesen approuve ce message )

Il y a des contre-exemples géniaux comme FAQ: foire aux questions

[ekieki]

éviter de programmer bourré.

[tomlev]

éviter de programmer bourré.

Pas forcément, c'est juste une question de dosage



Source: XKCD

[captaindidou]

Commenter ses modules :
- Statment of Problem
- Justification of design
- Implementation

Dans chaque sous-programme significatif :
Commenter l'algorithme

Le commentaire n'a pas vocation à faire des remarques mais à dire ce que l'on fait et pourquoi on le fait.


Tester unitairement même sommairement au fur et à mesure (j'ai tendance à ne pas le faire) de l'avancement du module.

Suivre les recommandations d'assurance qualité, en général.

[zsalloum]

Souvent la méthode agile est confondue avec rapidité. Du coup les dev crashent de code rapide juste pour résoudre un problème P, mais à force de faire cela le code devient impossible à comprendre et à maintenir.
Pour cela il est hyper important que la reflexion fait partie du sprint, afin de bien penser les modif.

Il est crucial de conserver un minimum de clareté dans le code

[Saverok]

Souvent la méthode agile est confondue avec rapidité. Du coup les dev crashent de code rapide juste pour résoudre un problème P, mais à force de faire cela le code devient impossible à comprendre et à maintenir.
Pour cela il est hyper important que la reflexion fait partie du sprint, afin de bien penser les modif.

Il est crucial de conserver un minimum de clareté dans le code

J'ai également constaté cette tendance à vouloir aller trop vite dans le contexte des projets en mode agile.
C'est pourquoi, j'impose tjrs la mise en place d'un analyseur de code (sonar par exemple) qui permet d'identifier rapidement les dérives sur la qualité du code.
Bien évidement, ça ne détecte pas tout mais au moins les bases comme le respect des normes de nommage, la duplication de code, les variables inutiles, etc.

Par contre, le travail en mode agile implique des développeurs expérimentés avec qui ces dérives n'arrivent pas (ou presque plus)
Pour des raisons de budgets, cela n'est pas possible et on se retrouve souvent avec un majorité de débutants et très peu de profils expérimentés...

[devyreham]

la modularisation est tout un concept assez discutable. Certains confondent module et package, créeant ainsi des modules non utilisables en dehors d'un groupe de module.
Exemple typique j'ai un module avec tous les "utilities", tous les autres en dépendent. Donc impossible à refactoriser sans tout casser ou prendre un mois.
Les codes unitaires sont parfaits: il a fallu donc les sortir de chaque classe et les remettres là où on s'en servait vraiment.

[Deuzz]

[HS]

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 ?

Juste pour rétablir la vérité : 4Ko c'était la mémoire vive. Il y avait quand même 32Ko de stokage (oui, je sais, c'est énorme ).
source

[/HS]

[sevyc64]

[HS]


Juste pour rétablir la vérité : 4Ko c'était la mémoire vive. Il y avait quand même 32Ko de stokage (oui, je sais, c'est énorme ).
source

[/HS]

Ouais sauf que moi, je parlais de la sonde Voyager 1.
Les bousins des Appolo, il y a un bail qu'ils n'ont pas vu la couleur d'un électron, alors que l'ordinateur de Voyager 1 fonctionne toujours, même, désormais, en dehors de notre système solaire.

Ceci dit, même que les 4Ko soit la ram, faire fonctionner un tel programme dans 4ko de ram, on en serait bien incapable de nos jours

[Deuzz]

Ouais sauf que moi, je parlais de la sonde Voyager 1.

Au temps pour moi. J'ai extrapolé bêtement dans la mauvaise direction mais comme tu as aiguisé ma curiosité et peut-être celle d'autres membres voici ce que j'ai trouvé sur Voyager I :

Du côté de l’informatique embarquée, on retrouve sur chaque sonde trois types d’ordinateurs (données de vol ; commande informatique ; contrôle de l'orientation et du mouvement) en deux exemplaires chacun, logés avec le reste de l'électronique embarquée dans la structure décagonale formant le coeur de chaque sonde. L'informatique dispose de son propre système d'autoprotection, qui rend la sonde capable de se "rebooter" elle-même en cas de problème, ce qui est capital pour sa survie étant donné son éloignement avec la Terre. La capacité totale des ordinateurs de chaque sonde s’élève à 68 KB, bien peu comparé aux ordinateurs modernes. Si besoin est, les données scientifiques peuvent être enregistrées puis retransmises ensuite vers la Terre. Les têtes de lecture de l'enregistreur de données sont extrêmement fiables : imaginez lire une cassette vidéo de 2 heures sur votre magnétoscope une fois par jour pendant 35 ans, sans aucun accroc. Chaque sonde dispose d'un enregistreur numérique d'une capacité de stockage de 500 MB. Du lancement des sondes jusqu'à Neptune, le volume total d'informations transmises s'élève à 5 000 milliards de bits, de quoi remplir plus de 7 000 CD de musique.

Source

[footsteps]

Laisser le père Noël développer le fichier persistence.xml.
La bdd est au pole Nord ,ca fait du chemin.
Plus sérieusement?THINK BEFORE ACT not act then think.

[Chen norris]

Des conseils qu'on lit effectivement à plein d'endroits mais qui restent tellement vrais. L'indentation pas respectée, les fotes d'aurtograff, les pavés de code commentés, l'absence de documentation, … Tant de bonnes pratiques qui passent aux oubliettes sous prétexte qu'on a un planning à respecter et que se relire pour bien remettre au propre, c'est tout sauf une priorité.

éviter de programmer bourré.

J'adore

[acaunensis]

Tous les points sont intéressants dans cet article.

Pour moi la LISIBILITE du code (donc aussi la bonne architecture et le bon choix de chacun des noms de variables et de fonctions) est PRIMORDIALE.
Si le code est peu lisible, même son auteur ne va pas s'y retrouver (bugs assurés).

Ceci justifie une orthographe précise et correcte.
Ce point justifie aussi que l'optimisation soit reléguée à la fin : une fonction optimisée à outrance est généralement illisible, donc boguée tôt ou tard ; pourquoi tôt ou tard ? parce que même si elle est juste au départ, la moindre modification/évolution sera erronée (comment modifier sans erreur une fonction illisible ou inutilement subtile ?)

Comme l'exprime O'Hare dans une phrase célèbre, une fonction clairement écrite est la seule qui soit vraiment fiable.

[acaunensis]

Tous les points sont intéressants dans cet article.

Pour moi la LISIBILITE du code (donc aussi la bonne architecture et le bon choix de chacun des noms de variables et de fonctions) est PRIMORDIALE.
Si le code est peu lisible, même son auteur ne va pas s'y retrouver (bugs assurés).

Ceci justifie une orthographe précise et correcte.
Ce point justifie aussi que l'optimisation soit reléguée à la fin : une fonction optimisée à outrance est généralement illisible, donc boguée tôt ou tard ; pourquoi tôt ou tard ? parce que même si elle est juste au départ, la moindre modification/évolution sera erronée (comment modifier sans erreur une fonction illisible ou inutilement subtile ?)

Comme l'exprime CAR Hoare dans une phrase célèbre, une fonction clairement écrite est la seule qui soit vraiment fiable.

(Exactement il a dit : « Il existe deux façon de concevoir un logiciel : une façon est de le faire si simple qu'il n'a visiblement aucun défaut, et une autre est de le faire si complexe qu'il n'y a pas de défaut visible. La première façon est de loin la plus difficile. »)