Discussion :

[fodger]

salut à tous,

j'ai répondu au questionnaire avec une autre question en tête :
"qu'est-ce qui me fait le plus progresser comme développeur?"

pour ma part c'est la curiosité: tester et apprendre de nouvelles technos, d'autres paradigmes, lire le code des autres, ...

Maintenant pour revenir à la question d'origine, je me la suis posée lorsque l'on prend des stagiaires dont j'ai la charge.
et au final ce qui est complétement rédhibitoire, c'est le manque d'autonomie:
quelqu'un qui va vouloir se faire aider sans essayer de chercher la solution par soi même, ça ne marchera pas

au final, je dirais que le bon développeur doit-être :
- relativement autonome,
- et doit pratiquer une veille assidu.

Cordialement

Tu ne peux pas reprocher à un stagiaire le manque d'autonomie, le propre du stage c'est de se former et gagner en autonomie.

Recrute vraiment dans ce cas.

[Saverok]

Si on maitrise vraiment le langage et qu'on teste vraiment unitairement ce qu'on fait, on ne devrait pas avoir besoin d'écrire des tests unitaires (techniques en tout cas) supplémentaire.

Quand on écrit des tests unitaires, ce n'est pas que pour soi.
On est rarement seul sur un projet et de même, on est rarement présent à 100% sur toute la durée de vie d'un projet.
C'est la même chose que pour la documentation.
Un TU, c'est un peu une doc technique ++ sur la manière dont a été testée et validée une fonction.

Pour en revenir au topic, je pense qu'une bonne habitude de programmation est de savoir s'approprier et se fondre dans la conception d'un programme.
Même si on est pas d'accord avec les choix effectués.
Même si on est pas en phase avec les normes mises en place.
On s'y astreint quand même.
Car sans cela, l'application au global devient rapidement un cauchemar de maintenabilité.
Je me suis trop souvent retrouvé sur des projets où chaque développeur avait voulu imposer "sa patte" ou "sa signature" et cela donnait un tout totalement incohérent.

[ternel]

Mes bonnes habitudes, celles qui réduisent énormément les coûts de développement?

• refuser
• négocier
• limiter
• s'amuser

C'est à dire:

• Refuser de faire un changement tant qu'il n'est pas spécifié.
• Négocier les moindres détails non spécifiés.
• Limiter le code aux spécifications.
• S'amuser à faire le code le plus propre, le plus efficace, le plus mieux, pour tout ce qui n'est pas spécifié.

C'est à dire: couvrir mes arrières en exigeant du chef de projet qu'il spécifie ce qui doit l'être.
Car un bon programme fait ce qu'il doit faire, ni plus ni moins.

Mon travail de développeur, c'est donc de faire en sorte de savoir ce que doit faire mon programme.

Bon, d'accord, il y a aussi chercher la simplicité, maitriser ses outils, comprendre le contexte, et réfléchir avant de coder

[abelar_s]

Je comprends que ce sont des astuces "de programmation" et que je propose autre chose.
Mais pour moi voici les grands absents :

* respecter et écouter les gens (étonnamment rare)
* se remettre en cause et s'améliorer (techniquement comme humainement)
* prendre soin de sa santé (mal dormir, manger, boire et la machine s'enraye)
* communiquer efficacement (communication non violente, savoir où est sa place et les contraintes au-dessus et en dessous, comme on connaît sa stack)
* s'attacher à livrer de la valeur : les trade-offs du code (simple/complexe, propre/rapide, abstrait/hardcodé) sont ou devraient être des arbitrages métier

[Tahrky]

Bonjour tout le monde !

Comment on peut développer intensivement sans but?

Ca dépend ce que l'on appelle un but, lorsque c'est imposé, dans le cadre d'un projet d'étude par exemple, le but, c'est la note, mais ce sera perçu très différement par pleins de gens.

Personellement, j'ai déjà programmer pour programmer, dans le sens : J'ai pas d'idées, mais je débute, ca m'exercera de le faire ...
(Autant dire que les projets n'ont jamais vu une quelconque lumière du jour, mais j'ai quand même appris des trucs)
On pourrait dire que j'ai programmer dans le but d'apprendre, mais je ne considère pas réellement ça comme un but dans ce cas là, tous dépend de la façon dont on interprète les choses.

En tant que débutant, j'ai choisi :

Écrire du code simple et être à l’affût de simplifications : Facilite la compréhension du code et de son fonctionnement, facilite la maintenabilité ... Que du bon.

Tout documenter et commenter : Même si le "tout" me déplait, je comprends et j'adhère à l'idée. Je pense que même si un nom clair permet de simplifier une grande partie du travail, de la documentation et des commentaires sont indispensables. Il m'est arrivé de devoir recourrir a des exemples de code pour trouver ce que je souhaitais, pour une documentation inexistante ou trop pauvre, ou bien de devoir aller fouiller le code source pour comprendre ce que la documentation n'expliquait pas (peu ou mal commenté d'ailleurs).

Ecrire du code lisibile et compréhensible : Ca rejoins pour moi ecrire du code simple, les arguments que je voudrais donner sont les mêmes ...

Corriger les bogues avant d’ajouter de nouvelles fonctionnalités : Je pense que si l'on écrit un code simple et lisible, laissé des bogues est un peu stupide (même si par contrainte de temps, il se peut que ...).

Je suis un débutant (2eme année de DUT, j'ai appris à programmer pendant la 1ère du DUT) et je poste aussi en partie pour avoir une trace de mon état de penser actuel, voir si quand j'aurais plus d'expérience (ou pas, qui sait ?), mon point de vue aura changer, en bien, ou en mal.

Cordialement,

Tahrky.

[zecreator]

Un bon développeur c'est avant tout une personne qui aime son métier. Généralement, quand on aime ce que l'on fait, que l'on ne voit pas juste son boulot comme un moyen "alimentaire", on est bon dans ce que l'on fait et on le fait bien.

[fodger]

Quand on écrit des tests unitaires, ce n'est pas que pour soi.
On est rarement seul sur un projet et de même, on est rarement présent à 100% sur toute la durée de vie d'un projet.
C'est la même chose que pour la documentation.
Un TU, c'est un peu une doc technique ++ sur la manière dont a été testée et validée une fonction.

Pour en revenir au topic, je pense qu'une bonne habitude de programmation est de savoir s'approprier et se fondre dans la conception d'un programme.
Même si on est pas d'accord avec les choix effectués.
Même si on est pas en phase avec les normes mises en place.
On s'y astreint quand même.
Car sans cela, l'application au global devient rapidement un cauchemar de maintenabilité.
Je me suis trop souvent retrouvé sur des projets où chaque développeur avait voulu imposer "sa patte" ou "sa signature" et cela donnait un tout totalement incohérent.

Merci pour le développement de ton point de vue, il est facile de désapprouver un message sans rien dire.

Je ne suis pas d'accord dans la mesure où on fait dire ce qu'on veut aux tests.
Ils ne garantissent pas de la qualité du code, et n'empêchent en rien la présence de bugs.

De plus ils allongent considérablement le temps de maintenance et augmentent la complexité d'un projet.

Ca peut avoir du sens sur des parties précises, critiques dont le comportement change peu (un kernel par exemple).

Mais généralement c'est plus efficace et rapide de faire tester par d'autres devs, ainsi que l'utilisateur final.

Je ne détiens pas la vérité absolue, c'est un retour personnel à partir de gros projets (il y a peu encore).

[fodger]

Pourquoi n'a t'on pas le fait de savoir écrire correctement en français et en anglais ?

C'est pourtant important pour le nommage des méthodes, variables, écrire une documentation concise et précise ...

[popo]

Fruit d'une formation aride et technique... nous retrouvons des solutions arides et techniques... logique.
Avec l'expérience, c'est surtout la qualité des échanges qui fait avancer les projets, le pair programming, la revue de code, synchro avec les besoins clients, savoir dire "ton code j'y comprends rien", "refaisons cette merde c'est inbitable"

Tout documenter et commenter => complètement idiot. À NE JAMAIS FAIRE. Le chapeau et rapidement ce que font les méthodes/fonctions. Une partie du code retord (pas par sa complexité algorithmique mais par les concepts qu'elles soulèvent derrière)
Parcourir toute la documentation => grosse perte de temps. Je vire celui qui me fait ça. Il ne sait pas gérer son temps.

Totalement d'accord.
La communication entre développeur est essentiel, ne serait-ce que pout éviter x personnes développent la même routine. Voire pire redéveloppent une routine du Framework : je l'ai déjà vu sur réimplémeté le LeftStr de Delphi où seul le nom des variables et de la fonction avaient changés, l'implémentation étant rigoureusement identique.

Pour la documentation, je pense que si on respecte le SRP, qu'on nomme bien les choses et qu'on écrit du code simple et lisible, les commentaires deviennent accessoires.
Pour moi un développeur qui a besoin de TOUT documenter, c'est un développeur qui doute de la qualité de son code où un développeur qui ne sais pas ce qu'il fait.
Idem un développeur qui lit TOUTES les documentations, est un développeur qui perd du temps et qui n'est donc pas efficace. Il vaut mieux lire la documentation sur un sujet précis au moment où on en a besoin.

Allô!

Je peux voir trois points importants:

1) Documenter le code.
2) Documenter le code.
3) Documenter le code.

Tout le reste, aussi bien le développement de tests unitaires, l'utilisation d'un bon IDE ou la communication à l'intérieur de l'équipe ne relève pas du programmeur mais du gestionnaire.

Mais ce n'est qu'un avis personnel, je ne prétends pas à la vérité...

Idem que précédemment sur la documentation.

Pour les tests unitaires, je ne peux que désaprouver :
Les tests unitaires sont de la responsabilité du développeur.
J'irai presque jusqu'à dire qu'un test unitaire est aussi important que la routine en elle-même.
Dans l'idéal, ce sera un autre développeur qui réalisera le test unitaire avant le développement de la routine elle-même.
Le test unitaire est là pour vérifier que son qu'on a développé fonctionne correctement.
C'est sur que si on écrit test unitaire à la va vite, ça ne sert strictement à rien.

.
Je ne suis pas d'accord dans la mesure où on fait dire ce qu'on veut aux tests.
Ils ne garantissent pas de la qualité du code, et n'empêchent en rien la présence de bugs.

De plus ils allongent considérablement le temps de maintenance et augmentent la complexité d'un projet.

Ca peut avoir du sens sur des parties précises, critiques dont le comportement change peu (un kernel par exemple).

On ne ferai pas dire ce qu'on veut aux tests s'ils étaient bien écrits et bien réfléchis.
On ne doit pas adapter un test unitaire à une méthode pour qu'elle passe en vert.
Je citerai pour appuyer mes propos, un grand homme qui changé la manière de développer de beaucoup d'entre nous :

Les tests sont aussi importants pour la santé d’un projet que peut l’être le
code de production. Ils sont peut-être même plus importants, car ils préservent et
améliorent la souplesse, les possibilités de maintenance et l’utilisabilité du code de
production

.
De plus ils allongent considérablement le temps de maintenance et augmentent la complexité d'un projet.

L'informatique de nos jour est beaucoup plus complexe que dans les année 80.
A l'époque, on posait un bouton, on double cliquait et on faisait une grosse requête dans le OnClick.
Cette façon de travailler est tout bonnement inadaptée au mode d'aujourd'hui.

Aujourd'hui, on ne travaille plus seulement derrière un ordi, on travaille sur sa tablette, sur son téléphone, etc.
On ne réécrit pas un produit au complet, on adapte simplement l'IHM mais le noyau reste le même.
Je fait de la maintenance comme n'importe quel développeur, et au niveau de mes tests unitaires cela reviens à écrire une nouvelle méthode de test pour gérer le cas qui m'avait échappé pour ensuite corriger mon code de production. Mon nouveau test sert à garantir que le bug est bien corrigé et les tests déjà existants m'assurent que je n'ai rien cassé ailleurs.

Pourquoi n'a t'on pas le fait de savoir écrire correctement en français et en anglais ?

C'est pourtant important pour le nommage des méthodes, variables

Tu m'enlève les mots de la bouche.

Bref tout ça pour dire que mon choix se porte sur :
- Écrire du code simple et être à l’affût de simplifications
- Écrire du code lisible et compréhensible
- Écrire des tests unitaires
- Corriger les bogues avant d’ajouter de nouvelles fonctionnalités
- Suivre régulièrement les technologies utilisées et leurs alternatives

[Bubonik software]

Si le développeur aime son métier (comme le disait zecreator) et code en gardant à l’esprit les besoins et contraintes de son client (un peu comme le disait leternel), je pense que c’est déjà beaucoup. Bien sûr, il faut aussi qu’il sache (au moins un peu) coder, débuguer, documenter, expliquer, simplifier, tester, optimiser…

[Invité]

Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ?

Avant de me lancer dans la programmation d'un projet, je commence toujours par écrire mon plan de travail sur une feuille de brouillon. Sur celui-ci, je note tout d'abord les grandes étapes du projet. Ensuite, j'approfondis chaque partie en visualisant plus ou moins le code qui sera nécessaire.

Par après, je relis mon plan en tenant compte de la gestion des ressources (Ai-je bien fermé chaque fichier ? Ai-je bien libéré les ressources mémoires ? ...) et de l'optimisation. J'essaye par exemple de voir s'il n'est pas possible de faire en une seule étape plusieurs sous-étapes dans mon programme.

Je commence alors à rédiger mon programme, un premier jet. Je corrige les bugs s'il ne fonctionne pas du premier coup, puis je teste mon programme. Si j'ai un doute sur l'utilisation d'une fonction, je consulte toujours la documentation (par exemple le site php.net quand je travaille en php), ou je pose des questions sur les forums. Pour chaque bloc d'instructions, je place un commentaire simple qui permet de comprendre ce qu'il se passe dans le programme. Je structure également mes commentaires en fonction du plan (je procède par parties, par sous-parties...).

Une fois mon programme fonctionnel, je le publie (open-source et libre d'utilisation, la programmation reste pour moi une passion) en espérant que d'autres programmeurs puissent m'indiquer comment l'améliorer.

Après amélioration du programme, je le termine en mettant par exemple "Version 1.0" en commentaire. Le programme terminé, me voilà heureux. :-D

Expliquez les avantages que vous en avez tirés.

Quand j'archive mes codes sources, par après, il est facile de les améliorer grâces aux commentaires qui facilitent la compréhension du code. Mais je réalise uniquement des petits projets, je n'ai pas encore eu l'occasion de programmer en groupe.

[djames]

Je préciserais dans la liste proposée :
- écrire du code lisible et compréhensible

=> notamment des noms de variables longs et explicites

- écrire du code simple

=> notamment découper en fonctions à mono responsabilité

Je rajouterais cette petite technique efficace :
- avant d'écrire le code, écrire en commentaire l'algorithme en pseudo code

=> cela permet d'économiser pas mal de retouches, de trouver des optimisations à l'avance et à la fin on a déjà les commentaires

Quand c'est possible
- relire et se faire relire

=> on découvre chez les autres ou chez soi des bonnes/mauvaises pratiques qu'on ne voit pas tout seul

- utiliser un framework qui 'impose' de bien coder (ex: angular en js)


Par contre je suis plutôt réservé sur :
- écrire des tests unitaires

=> dans la pratique trop long à maintenir.

- veille technologique

=> attention à ne pas tomber dans le travers d'utiliser des technos pas assez mûre et de se retrouvé planté

[champy]

Surtout varier ces développements et ces langages quitte à la faire chez soi.

Faire de la POO pendant 10 ans et passé de force au JavaScript (bas oui tu comprends l'application est desktop mais faut la faire en web) sa en déroute beaucoup qui ne peuvent plus remettre en cause les paradigmes de programmation qu’ils ont appris et tenterons coûte que coûte de les reproduire avec les conséquences que l'on connait (la création de FrameWork perso pour faire de la POO en JavaScript, l'horreur absolue).
Exemple criant de vérité lorsque l'on lit les joutes emballées POO vs JS présente sur ce site
L'inverse est vrai aussi un développeur JavaScript qui se met au C aie, aie, aie ça fait mal.

Le point le plus délicats pour moi c'est le chiffrage, bien chiffré son projet c'est avoir pris conscience de tous les pans de l’application, cahier des charges, analyse, développement, technologies utilisées, migration de données, commentaire, guide utilisateur, intégration dans l'usine logiciel, et j'en passe. Le problème étant que ton chiffrage tu dois le faire vite, souvent à l'oral, alors qu'il faudrait presque faire une maquette pour ce rendre réellement compte de tous se qu'implique le projet. Je pense que je vais finir par chiffrer le chiffrage

Car derrières, on a les décideurs et leur dead line commerciale qui de toute façon ont été décidé avant ton chiffrage
Toujours envoyer un chiffrage par mails pour pouvoir rétorquer quand on te dit 'ce n’est pas finit !! Mais c'est déjà vendu !!!' , 'bas il y a encore 6 mois de développement dans le chiffrage'

Les tests, LE sujet, anecdote récente, personne ne fait de TDD dans notre équipe en fait je suis le seul à faire des tests, je développe tous ce qui est Web et il faut bien avouer que du Web sans test c'est la catastrophe (je parle de grosse WebApps pas de site E-Commerce ou autre WordPress).

On développe un gros projet de gestion de patrimoine autoroutier orienté SIG (état des ponts, de la chaussée, camion de patrouille en live sur la carte, indicateur de performance , gestion de la maintenance, des incidents, des interventions ... ), les décideurs vendent, je chiffre les modules , et un mois après on me dit , on vas faire de la qualité , on vas développer tous les modules en TDD et bien multiplie le chiffrage par 4, je suis le seul à avoir une culture du test (pour développer des tests notamment unitaire le code doit être orienté, finit les méthodes qui font 50 trucs même pour l’algorithme) , du coup abandon du TDD pour les premiers modules (et à mon avis pour les suivant)

Mais quand je lis sa

Ils ne garantissent pas de la qualité du code, et n'empêchent en rien la présence de bugs.

et tu le sort comment ton indicateur qualité (ou alors tu le sort pas du tout, quand même pas !) ?
A la limite en étant très (trop) pragmatique et uniquement sur des Dead line ultra serré pas de test lors du développement (je sais ce n’est pas bien mais pas le temps) en revanche au premier bug, test de non régression OBLIGATOIRE car la résurgence d'un bug déjà corrigé est ce qu'il y a de pire pour l'expérience utilisateur.

Par contre tout le monde parle de test unitaire, c'est bien, mais pour moi les tests fonctionnels doivent être privilégié, ils sont beaucoup moins chronophage et peuvent être ajouté à un projet sans modifier le code.

Pour les commentaires, je me rappelle de cette époque :

Code :

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

1
2
3
4
5
/// <summary>
/// Chaine de connexion pour se connecter à la base de données
/// </summary>
public String ConStr { get; private set; }

Qu'est-ce que sa servait à rien, ha si aucun Warning pendant la génération de la documentation

Maintenant je ne documente que ce qui as besoin de l’être, les algorithmes, les interactions internes et externes, mais surtout je nomme beaucoup mieux mes variables.
Je me fiche de l’orthographe une collection ou un tableau prend toujours un s, j'utilise du Franglais volontairement quand la notion métier derrière la variable est plus difficile à comprendre en anglais.
Bon c'est un peu de la vengeance j'ai brûle mon bled après le collège.

L'autre pan certainement le plus important les relations humaines , cela vas du respect de ses collègues ,aider les gens moins compétent mais sans leur reprocher leur lacune (car on as tous des lacunes), communiquer sur ce que l'on fait et demander aux autres ce qu'il font pour mutualiser le tout , garder à l'esprit que tu dois transmettre aussi des compétences métier et pas uniquement informatique.

Mais surtout savoir être intraitable avec ta direction (en restant courtois et intelligent), c'est ton job, il ne connaisse pas la programmation (je bosse dans un grand groupe) et planifierons les livraisons sur des besoins commerciaux si tu ne leur dit rien, il ne faut pas hésiter et ne pas se sentir inférieur (le complexe col blanc col bleu est à bannir)

Exemple : sa doit être compatible IE6 pour cibler le plus de client possible tu comprends on cible l’internationale, la tu dis non et tu proposes une prestation de migration vers au moins IE X (même irréaliste) dans leurs yeux les dollars brillent, le client refuseras peut être car son parc d'application à besoin d'IE6 mais ça c'est plus ton problème, ça devient le leurs

[Pyramidev]

Pour la documentation, je pense que si on respecte le SRP, qu'on nomme bien les choses et qu'on écrit du code simple et lisible, les commentaires deviennent accessoires.

Je suis toujours stupéfait chaque fois que je lis que, si on programme comme il faut, les commentaires deviennent accessoires.

Voici quelques cas où les commentaires sont utiles et ne peuvent être compensés par un bon nommage et un code simple et lisible :

• Soit un code de la forme :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  void uneFonction()
  {
      // faire un truc A
     ligne de code
     ligne de code
     ligne de code
     ligne de code
  
      // faire un truc B
     ligne de code
     ligne de code
     ligne de code
  
      // faire un truc C
     ligne de code
     ligne de code
     ligne de code
     ligne de code
     ligne de code
  }

  Ce code donne au lecteur, sous ses yeux, à la fois une vision globale (s'il ne lit que les 3 commentaires) et une vision détaillée (s'il lit chaque ligne de code).
  Si, à la place, on écrit :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  void uneFonction()
  {
      faireUnTrucA();
      faireUnTrucB();
      faireUnTrucC();
  }

  avec des sous-fonctions qui ne sont utilisées qu'ici, alors le lecteur a toujours la vision globale. Mais, pour avoir une vision détaillée, c'est moins pratique car il faut lire séparément le code de chaque sous-fonction.
• Les commentaires sont utiles pour les préconditions et les postconditions des fonctions.
  Exemple en C++ :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  /*!
   * \details Les formats de date actuellement supportés sont
   *          "AAAAMMJJ", "AAAA-MM-JJ" et "JJ/MM/AAAA".
   */
  boost::optional<Date> toDate(const std::string& s);
  
  /*!
   * \return Un indice si l'élément est trouvé, -1 sinon.
   * \remark La numérotation des indices commence à 0.
   */
  int findIndex(const MyCollection& collection, const Element& searchedElement);

  C'est quand même mieux que :
  

  Code :

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

  1
  2
  3
  boost::optional<Date> toDate(const std::string& date_AAAAMMJJ_ou_AAAATiretMMTiretJJ_ou_JJSlashMMSlashAAAA);
  
  int findZeroBasedIndexOrMinusOneIfNotFound(const MyCollection& collection, const Element& searchedElement);

• Dans des langages sans ramasse-miette, la documentation est importante pour gérer la mémoire.
  Exemple en C++ :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  class Foo
  {
      // ...
      /*!
       * \param config Cet objet doit exister tant que Foo existe.
       */
      Foo(const Config& config);
  
      /*!
       * \return Si l'élément est trouvé, le pointeur retourné est valide tant que Foo existe et possède cet élément.
       */
      Element* findElement(const ElementId& elementId);
      // ...
  };

  Sans les commentaires, le lecteur pourrait supposer que le constructeur de Foo fait une copie du paramètre (donc on se fiche de la durée de vie de config) ou que findElement retourne un pointeur qui risque de ne plus être valide au prochain appel d'une fonction de Foo.
  Ce genre d'information a plus sa place dans les commentaires que dans le nom des fonctions ou des variables.
• Dans le cas très spécial où la robustesse du programme est prioritaire sur le respect d'une deadline serrée, on prend en compte avec soin le cas où une erreur se produit (ex : échec de copie d'un fichier).
  Alors, dans le cas où une telle erreur survient, il est bon de savoir dans quel état seront les données. Garantit-on qu'elles sont inchangées ? qu'elles restent dans un état cohérent ? Dans le cas où ces erreurs sont propagées par des exceptions, on parle d'exception safety, de strong guaranty et de basic guaranty.
  Ce genre d'information a plus sa place dans les commentaires que dans le nom des fonctions.

[fodger]

et tu le sort comment ton indicateur qualité (ou alors tu le sort pas du tout, quand même pas !) ?

Les outils d'intégration continue sont là pour ça (Jenkins, sonar...).

Et je maintiens qu'un dev qui sache pas écrire sans faire une faute tous les deux mots est un problème, n'en déplaise à certains.

[ddoumeche]

Personnellement (j'insiste) et par expérience,
je trouve que les tests unitaires automatisés peuvent être utiles mais à petit dose car ils souffrent à mon sens de gros points négatifs :
- Chronophage (peut-être plus longs à écrire que l'appli elle-même).
- Complexe à écrire (en tout cas PHPUnit c'est chiant :p).
- Peut allégrement servir de cache misère ("ah ben non nos tests unitaires sont bons").
- Ne reflète pas, mais alors pas du tout, la qualité intrinsèque du code.

Si on maitrise vraiment le langage et qu'on teste vraiment unitairement ce qu'on fait, on ne devrait pas avoir besoin d'écrire des tests unitaires (techniques en tout cas) supplémentaire.

Donc à chaque fois que tu relivres une application, tu testes toutes, absolument toutes les fonctionnalités, à la main ?

[ChristianRoberge]

Coder intensivement, documenter et test, personne n'est contre la vertu, nous dira-t-on! Moi, j'ose dire que trop de vertu conduit à une très mauvaise programmation. Trop de documentation est une perte de temps si nous noyons les informations essentielles par des milliers de pages de détails insignifiants. La documentation devrait se limiter à ce qu'un programmeur moyen ne peut déduire facilement en regardant le code (Je suppose ici que le code est lisible). Trop de test est stupide et aussi une perte de temps. Un test devrait vérifier des spécifications précises du projet et non que 1+1 = 2. Je vois beaucoup de gens s'appuyer sur des tests de trop bas niveau pour dire que leur application fonctionne. L'important d'en test n'est pas de savoir si une inversion matricielle est fonctionnelle. Si les tests de haut niveau échouent, la structure même du code devrait nous amener à identifier rapidement ce qui ne va pas. Donc, il faut bien penser et structurer avant de coder. En coder intensément, ne sert à rien tant qu'à moi. Entre un programmeur qui réalise une fonctionnalité en 2 jours de travail en produisant 10,000 lignes de codes et celui qui prend 10 jours pour produire la même fonctionnalité en 300 lignes de programmation, je préfère de beaucoup la dernière alternative. Trop souvent, les "impulse" programmeurs sont appréciés dans l'industrie, mais on n'oublie trop souvent que l'entretien et la mise à jour de 10,000 est très long et couteux.
Pour moi, les bonnes habitudes sont des questions de dosage et surtout être capable de reconnoitre quel dosage nécessite ce projet. Il faut beaucoup de documentation pour les projets très complexe. Il faut beaucoup de test "unitaire" lors de l'écriture de grandes librairies dont les éléments risques d'être utilisé dans des contextes très variées.
Ma définition de bonnes habitudes de programmation est d'être un programmeur paresseux. On fait le minimum de code, de documentation et de tests qui rencontrent les spécifications de l'application et, cela est ici très important, qui permet à quiconque de corriger le code et de l'adapter, s'il y a lieu, à d'autres projets ou de nouvelles spécifications dans un minimum de temps et d'effort. (Donc un minimum intelligent!!!)

[fodger]

Mon nouveau test sert à garantir que le bug est bien corrigé et les tests déjà existants m'assurent que je n'ai rien cassé ailleurs.

Il ne garantit en rien que tu ais écrit un code de qualité, intelligent et que tu ais réellement couvert toutes les situations.
Le test par un tiers avec de l'intégration continue restent très efficaces.

[fodger]

Coder intensivement, documenter et test, personne n'est contre la vertu, nous dira-t-on! Moi, j'ose dire que trop de vertu conduit à une très mauvaise programmation. Trop de documentation est une perte de temps si nous noyons les informations essentielles par des milliers de pages de détails insignifiants. La documentation devrait se limiter à ce qu'un programmeur moyen ne peut déduire facilement en regardant le code (Je suppose ici que le code est lisible). Trop de test est stupide et aussi une perte de temps. Un test devrait vérifier des spécifications précises du projet et non que 1+1 = 2. Je vois beaucoup de gens s'appuyer sur des tests de trop bas niveau pour dire que leur application fonctionne. L'important d'en test n'est pas de savoir si une inversion matricielle est fonctionnelle. Si les tests de haut niveau échouent, la structure même du code devrait nous amener à identifier rapidement ce qui ne va pas. Donc, il faut bien penser et structurer avant de coder. En coder intensément, ne sert à rien tant qu'à moi. Entre un programmeur qui réalise une fonctionnalité en 2 jours de travail en produisant 10,000 lignes de codes et celui qui prend 10 jours pour produire la même fonctionnalité en 300 lignes de programmation, je préfère de beaucoup la dernière alternative. Trop souvent, les "impulse" programmeurs sont appréciés dans l'industrie, mais on n'oublie trop souvent que l'entretien et la mise à jour de 10,000 est très long et couteux.
Pour moi, les bonnes habitudes sont des questions de dosage et surtout être capable de reconnoitre quel dosage nécessite ce projet. Il faut beaucoup de documentation pour les projets très complexe. Il faut beaucoup de test "unitaire" lors de l'écriture de grandes librairies dont les éléments risques d'être utilisé dans des contextes très variées.
Ma définition de bonnes habitudes de programmation est d'être un programmeur paresseux. On fait le minimum de code, de documentation et de tests qui rencontrent les spécifications de l'application et, cela est ici très important, qui permet à quiconque de corriger le code et de l'adapter, s'il y a lieu, à d'autres projets ou de nouvelles spécifications dans un minimum de temps et d'effort. (Donc un minimum intelligent!!!)

Salut, j'abonde dans ton sens par contre pourrais-tu stp passer des lignes ?

[fodger]

Quand on écrit des tests unitaires, ce n'est pas que pour soi.
On est rarement seul sur un projet et de même, on est rarement présent à 100% sur toute la durée de vie d'un projet.
C'est la même chose que pour la documentation.
Un TU, c'est un peu une doc technique ++ sur la manière dont a été testée et validée une fonction.

Pour en revenir au topic, je pense qu'une bonne habitude de programmation est de savoir s'approprier et se fondre dans la conception d'un programme.
Même si on est pas d'accord avec les choix effectués.
Même si on est pas en phase avec les normes mises en place.
On s'y astreint quand même.
Car sans cela, l'application au global devient rapidement un cauchemar de maintenabilité.
Je me suis trop souvent retrouvé sur des projets où chaque développeur avait voulu imposer "sa patte" ou "sa signature" et cela donnait un tout totalement incohérent.

Ce n'était pas mon propos,

Je parle pas de faire pour soit les tests unitaires ou non.
D'ailleurs tu testes unitairement ce que tu codes par respect pour les autres mais également pour toi même si tu as un peu d'amour-propre.

Je ne parle pas du fait que chaque développeur "impose" sa patte, je parle de la pertinence du tout test unitaire technique.

Beaucoup se reposent, se rassurent avec ça mais je maintiens que ça ne garantie pas la qualité d'un code. Je l'ai trop souvent vu.

Il est bien plus important, et impactant de savoir écrire, suivre les bonnes pratiques, comprendre et maîtriser le langage utilisé.