Coder proprement et bons réflexes de programmation

[Holy]

Je prends l'initiative suite à un débat (intense) dans un autre sujet du forum de poser une question qui peut sembler banal mais qui reste pourtant fondamental : Que veut dire "coder proprement" ?

De cette première question en découle une autre : "Comment coder proprement ? Quels réflexes avoir lorsqu'on code ?"

Je sais qu'il y a pas mal de sites qui reprennent ce type de sujet mais dans le cadre du jeu vidéo, ça pose pas mal de question, notamment en termes de compromis entre performance et maintenabilité du code.

Si vous avez des ressources là-dessus, notamment sur "comment documenter et commenter son code", ça m'intéresse beaucoup ^^. Un tutorial sur javadoc serait vraiment sympa.

Sinon, à titre personnel, il y a quatre choses qui me semblent essentielles avant de commencer un projet (que ça soit dans un FWork ou pas) :
- Rédiger des conventions de nommage de variables et de fichiers.
- Réfléchir à une arborescence de projet qui soit suffisamment claire.
- Choisir un mode de développement qui permette de rapidement savoir où se trouve quoi (MVC, ...).
- Documenter autant que possible son code.

[Ter Rowan]

ma position professionnelle (pas en tant que développeur , je ne suis pas bon, mais en tant que responsable d'une entité qui fait développer des prestataires)

- utilisation de frameworks connus, documentés
- utilisation de peu de frameworks (la multiplication nuit)
- une architecture simple (inutile de faire le dernier truc à la mode ou l'architecture la plus ouverte à un tas de possibilités si le besoin ne le nécessite pas)
- utilisation d'un langage connu, reconnu et partagé, par l'entreprise tout comme par les SSII* du marché (aujourd'hui, pour moi, ça veut dire .net, java, et dans une moindre mesure php pour le côté serveur, pour le côté client, on est bien embêté, finalement pas grand monde* connait autre chose que html et javascript)
- utilisation de design pattern (et/ou autre modélisation) en quantité limité (la multiplication nuit), les moins subtiles possibles. Y a pas que des cadors qui développent. Y a surtout des gens moyens qui développent
- normes (nommage, utilisation du gestionnaire de sources, etc...)
- éviter le procédural pour privilégier la poo (voire utiliser l'événementiel ou le fonctionnel, mais beaucoup moins de monde* connait autre chose que poo ou procédural)
- commenter correctement le code
- documenter correctement le programme (architecture, processus, use case, ...)
- intégrer des tests (unitaires voire d'intégration, voire fonctionnels) de manière automatisé (si je recompile, je dois avoir déjà une idée du ça marche, ça marche pas)


ma position personnelle/artisanale/de plaisir

- faire au mieux en fonction de ses connaissances pour être satisfait de soi (et chacun n'est pas satisfait de la même manière)
- commenter le code, voire documenter (mais uniquement si on est prêt à revenir sur la documentation quand on revient sur le code)
- privilégier la modélisation que l'on sait utiliser (ex : si on sait faire poo et procédural, privilégier poo, si on ne sait pas faire de poo, faire du procédural)
- privilégier un langage avec des communautés bien établies
- privilégier un langage avec une syntaxe qui plait à l'équipe (si plusieurs personnes sur le projet) si une équipe adore l'assembleur, qu'elle fasse son truc en assembl...eurk :p

- privilégier des frameworks si ceux si plaisent (cf fonction point 1) ou font des choses qu'on ne saura pas faire sans une lourde réflexion (typiquement pour moi, framework php ne me fait pas plaisir donc je n'en prends pas, mais comme je ne sais pas faire aisément du javascript "riche", je choisirai un framework javascript)
- privilégier un découpage de l'activité fonction du plaisir (exemple, privilégier un découpage qui permet de montrer l'avancée des résultats)





*"SSII", "grand monde" dont je parle = grosses boîtes (cap gemini, logica, accenture, etc...) voire moindre, mais pas boîte de niche ou start up, là je ne connais pas, pour la simple. Evidemment on trouvera d'autres compétences dans ces boîtes là, mais pour obtenir rapidement une équipe de 10 personnes pour un projet, c'est les technos qu'il faut privilégier aujourd'hui si on veut être serein sur la capacité de l'équipe à réaliser dans des temps... raisonnables, de même pour la pérennité de l'équipe de maintenance

[niahoo]

Que penses tu d'une équipe qui utilise un environnement avec une communauté réduite mais qui le maitrise très bien ?
(à la condition pas forcément évidente que tu travailles avec eux sur le long terme, sans faire glisser le projet d'équipe en équipe)

hmm je crois que je dévie un peu du sujet donc je risque juste de répondre « ok », c'est juste pour avoir ton avis.

[Hideaki]

Je rejoins Ter Rowan sur son point de vu surtout pour le côté professionnelle (d'ailleurs tu as cité une de mes anciennes boîte ).

Je pense qu'on peut allier les 2 positions dans la majorité des cas ^^ (à condition d'être à la création du projet).

[Ter Rowan]

Que penses tu d'une équipe qui utilise un environnement avec une communauté réduite mais qui le maitrise très bien ?
(à la condition pas forcément évidente que tu travailles avec eux sur le long terme, sans faire glisser le projet d'équipe en équipe)

hmm je crois que je dévie un peu du sujet donc je risque juste de répondre « ok », c'est juste pour avoir ton avis.

sur une longue période tu es certain de devoir remplacer des gens (soit parce qu'ils changent de boîte, soit parce qu'ils évoluent dans leur boîte) De plus ceux qui restent ne sont pas forcément les meilleurs ou les plus aptes à évoluer dans leur comportement (la super techno d'aujourd'hui ne vaut peut être plus rien dans 15 ans)

conclusion soit l'équipe est importante sur une techno "rare" ( > 10-20) et tu peux te dire, je gère le turn over en embauchant des petits jeunes que je vais former à ma techno "rare", (même principe pour une méthodo),

soit ce n'est pas le cas, ou encore pour des raisons financières, tu estimes que ce n'est pas rentable (tenir compte du risque, ce n'est pas que le coût évident) et dans ce cas tu chercheras à avoir du stable, du connu, de l'éprouvé, etc...

typiquement j'ai encore dans mon parc d'application à gérer quelques technos(langage ou framework) rares héritées d'anciennes organisations. Pas forcément mauvaise en soi. Eventuellement même performante.

Et ben c'est la croix et la bannière pour trouver des mecs compétents dessus, même pour les fournisseurs que j'ai pu cité. Du coup ça nous coûte aussi 3 fois plus cher (rareté oblige) Conclusion, premier réflexe, tuer l'application, la remplacer, etc...

L'innovation, ou les technos rares, je pense qu'on les trouvera, dans les start up, dans les équipes ultra spécialisés dans un métier (salle de marché, armement, aviation , nucléaire, etc...), et dans les sociétés d'édition informatique. Pour le reste, soit la grande majorité, ce que j'appellerai l'informatique de gestion (ou à papa), ce qui compte c'est d'être tranquille, donc de prendre du connu. Il faut quand même se dire que la plupart des boîtes n'ont pas pour coeur de métier l'informatique, leur problème c'est de vendre des produits, pas de développer des super programmes.

Et l'une de ces technos pourra devenir un standard demain, si elle apporte un plus remarquable (au sens marketing du terme)

si jamais on (indéfini) arrive a vendre que XXXX est LE langage de développement du prochain support (tablette, smartphone, ....) que tout le reste est has been, moins performant, plus couteux, etc... alors le XXXX de niche deviendra un standard, les boîtes, à tord ou à raison, solliciteront les SSII en précisant ce langage, les SSII investiront/recruteront des jeunes sur ce langage, et on revient au statut normal

[niahoo]

ok

Il faut quand même se dire que la plupart des boîtes n'ont pas pour coeur de métier l'informatique, leur problème c'est de vendre des produits, pas de développer des super programmes.

tiens oui c'est pas faux. enfin, j'espère que tu généralises beaucoup !

[Mycroft]

En général, "code proprement" en tout cas pour moi, ça veut surtout dire " être lisible ".

C'est essentiel quand on travaille à plusieurs, mais même seul, ça permet de gagner un temps fou quand un an ou deux après il s'agit de retrouver un bug à cet endroit.

C'est pas toujours évident de se replonger dans ce qu'on faisait il y a six mois.

En gros pour moi ça veut dire :
- des noms de variables et de fonctions très explicites : en lisant la fonction on doit comprendre ce que ça fait de façon non ambigüe.

Par exemple, si une fonction s'appelle getPosition elle ne doit retourne qu'une position, si elle retourne une position et un temps, renommmer en : getPositionAndTime. Accessoirement dans getPosition, on ne doit pas s'amuser à setter d'autres valeurs discrètement...

- Au niveau de l'écriture ou des algos, pour moi ça sert à rien d'écrire un code plus compacte ou plus efficace de 30% si c'est pour perdre en lisibilité. (sauf cas exceptionnelle).

Parce qu'écrire un algo très complexe, c'est pas sûr que quelqu'un d'autre soit en capacité de la modifier le jour ou il le faudra.

- Au niveau des commentaires, c'est important de ne pas en écrire trop qui sont inutile du style :

Code :

// Get the Position
position = getPosition();

Par contre c'est IMPERATIF de commenter si vous faites quelque chose de non triviale ou d'inattendu.
C'est pour éviter que quelqu'un ne tombe sur le code et se demande pourquoi c'est comme ça. Ou ne soit tenter de virer cette ligne.

Un exemple relativement récent : dans du code pour openSSH, une fonction utilisait une variable non iniatialisée, chose que dans une cas normal on ne fait jamais. Vraisemblabement c'était pas commenté. Quelqu'un est passé derrière et en pensant bien faire à réinitialiser cette variable à 0. Résultat : grosse faille de sécurité dans SSH sous Debian.

(La raison d'utiliser une variable non initialisée, c'était pour augmenter 'l'aléatoire' dans le code. En lisant une zone qui est jamais identique à chaque appel et qui dépend de l'état du système)

Je pense qu'il y a pas mal d'autres sujets importants mais c'est tout ce qui me passe par la tête pour le moment.

[Viciousity]

Surtout pour les commentaires, essayer de definir clairement le méchanisme si il n'est pas trivia afin que l'on puisse peut etre l'améliorer sans en changer la nature.

# Return an array with @size children with random values between 0 & @base.

def random_array size, base

  range = (0..base).to_a

  array = []

  size.times do

    array << range.shuffle.first

  end

  return array

end



# Comme sa quelqu'un en lisant le commentaire pourrait la transformer comme ceci :

def random_array size, base

  array = []

  size.times do array << rand(base+1) end

  array

end

[Myrina]

Il y a un énorme travail à effectuer préalablement au codage qui pourrait se résumer en:

Ce qui se conçoit clairement, s'énonce clairement.

Donc pour "coder proprement", hormis les diverses conventions fixées, il faut également avoir conçu de manière claire ce que l'on souhaite coder: l'analyse

[Prirawien]

Il faut distinguer l'environnement de travail. Au milieu professionnel, c'est souvent un travail d’équipe, ce qui implique les mêmes règles pour tous les programmeurs. Et même quand ça ne l'est pas, il faut penser a notre remplaçant qui devra probablement retravailler nos sources.

Au milieu personnel, on se fixe nous même nos propres règles. J'estime que mon code est propre quand, lorsque je m'y replonge quelques mois après, je peux travailler dessus au bout de quelques minutes (et pas une demi-douzaine d'heures pour comprendre ce a quoi je pensais...)