Discussion :

[Pyramidev]

J'ai, dans ma vie professionnelle, eu la chance de n'avoir jamais eu à "pisser du code", mais plutôt à passer du temps à réfléchir comment je coderais le moins possible.
Sur ce sujet, Bill Gates dit: "I chose a lazy person to do a hard job. Because a lazy person will find an easy way to do it".. et pour trouver l'"easy way", ben faut réfléchir, et pas "pisser"

Le problème, c'est que, parmi les manières de taper le moins de code possible, il y a :

• ignorer les cas d'erreurs (ex : fichier au mauvais format) ;
• ne rien loguer ;
• ne pas écrire de tests unitaires ;
• grossir des fonctions au lieu de les décomposer en sous-fonctions ;
• copier-coller au lieu de factoriser ;
• ne pas faire d'encapsulation, car coder des wrappers demande de taper plus de code ;
• introduire plein de variables globales, car passer des informations de paramètre en paramètre demande de taper plus de code...

...puis, quand la productivité commence à trop baisser à cause du travail bâclé, fuir vers un autre poste et laisser les futurs développeurs galérer à maintenir le code pourri.

Donc, non, un bon développeur n'est certainement pas un développeur qui cherche à taper le moins de code possible.

Un bon développeur n'est pas non plus un développeur paresseux, bien au contraire.

[didier.cabale]

Le problème, c'est que, parmi les manières de taper le moins de code possible, il y a :

• ignorer les cas d'erreurs (ex : fichier au mauvais format) ;
• ne rien loguer ;
• ne pas écrire de tests unitaires ;
• grossir des fonctions au lieu de les décomposer en sous-fonctions ;
• copier-coller au lieu de factoriser ;
• ne pas faire d'encapsulation, car coder des wrappers demande de taper plus de code ;
• introduire plein de variables globales, car passer des informations de paramètre en paramètre demande de taper plus de code...

Ne détournez pas mon propos. Je n'ai pas préconisé d'écrire le moins de code, mais de proposer la solution la plus simple ("écrire le moins de code" étant un raccourci sémantique) POSSIBLE. Tout en respectant les bonnes pratiques que vous aurez défini, vous pouvez parfaitement considérer qu'un code est inutilement complexe.
Le seul bémol que j'apporterais à mon avis initial est que la concision du code (ou de la proposition) ne doit pas sacrifier sa lisibilité.

[Saverok]

Le problème, c'est que, parmi les manières de taper le moins de code possible, il y a :

• ignorer les cas d'erreurs (ex : fichier au mauvais format) ;
• ne rien loguer ;
• ne pas écrire de tests unitaires ;
• grossir des fonctions au lieu de les décomposer en sous-fonctions ;
• copier-coller au lieu de factoriser ;
• ne pas faire d'encapsulation, car coder des wrappers demande de taper plus de code ;
• introduire plein de variables globales, car passer des informations de paramètre en paramètre demande de taper plus de code...

...puis, quand la productivité commence à trop baisser à cause du travail bâclé, fuir vers un autre poste et laisser les futurs développeurs galérer à maintenir le code pourri.

Donc, non, un bon développeur n'est certainement pas un développeur qui cherche à taper le moins de code possible.

Un bon développeur n'est pas non plus un développeur paresseux, bien au contraire.

Il s'agit de paresse intelligente et non de celle du bof de base.
Factoriser et découper ton code en plusieurs sous-fonctions prends plus de temps au début mais au final, sur le global du programme, ça te fait énormément gagner de temps au fil du développement du programme (car tu réutilises de plus en plus le code déjà écrit au début).
Même chose pour les logs qui prennent du temps à écrire mais lors du débugage, ça fait gagner un temps de dingue.
Autrement dit, c'est bien de la paresse mais effectuée sur une vision globale de l'ensemble du projet à développer voir même sur l'exploitation du projet une fois en production et non une paresse stupide basée uniquement sur l'instant présent.

On peut passer ce fameux test PAPI en ligne pour se faire une idée ?

Oui, il existe plein de tests gratuits sur le net que je te laisserai chercher

Ca peut paraître assez bidon quand on le fait mais au final, ça peut révéler certaines choses mais c'est surtout un excellent support de discussion quand on débriefe le rapport avec le candidat.
Ce n'est surtout pas à prendre au pied de la lettre.

[el_slapper]

(.../...)Ca peut paraître assez bidon quand on le fait mais au final, ça peut révéler certaines choses mais c'est surtout un excellent support de discussion quand on débriefe le rapport avec le candidat.
Ce n'est surtout pas à prendre au pied de la lettre.

Donc c'est dangereux. Ca va forcement finir dans les mains qui prendront ça pour paroles d'évangile.

[VivienD]

[...]

Ca peut paraître assez bidon quand on le fait mais au final, ça peut révéler certaines choses mais c'est surtout un excellent support de discussion quand on débriefe le rapport avec le candidat.
Ce n'est surtout pas à prendre au pied de la lettre.

Donc c'est dangereux. Ca va forcement finir dans les mains qui prendront ça pour paroles d'évangile.

Comme si ce qu'il est advenu des statistiques ne constituait pas une bonne mise en garde en la matière...

[Saverok]

Donc c'est dangereux. Ca va forcement finir dans les mains qui prendront ça pour paroles d'évangile.

Bien sûr et alors ?
Un couteau c'est dangereux aussi car on peut se couper quand on fait pas gaffe et y a même des cinglés pour les utiliser et tuer aveuglément dans la rue avec.
Alors qu'est ce qu'on fait ? On interdit les couteaux ?
Ou on agit en adulte responsable et on les utilise intelligemment en gardant en tête les règles de sécurités de base lorsqu'on les manipule ?

C'est la même chose pour le test PAPI comme des millions d'autres choses.
Oui, tu vas avoir des abrutis qui vont prendre ça au pied de la lettre et alors ? Est-ce une raison pour ne pas les utiliser ?

[Pyramidev]

Autrement dit, c'est bien de la paresse mais effectuée sur une vision globale de l'ensemble du projet à développer voir même sur l'exploitation du projet une fois en production et non une paresse stupide basée uniquement sur l'instant présent.

Au final, nous sommes d'accord sur les idées, mais pas sur le vocabulaire.

Dans le dictionnaire de l'Académe française, 9e édition, la définition de paresse est : « Disposition qui porte à éviter l'effort, le travail, à négliger de remplir ses obligations, à se complaire dans l'oisiveté. »

Faire un bon travail sur le long terme pour que le projet soit facile à maintenir, même quand on ne sera plus dessus, ce n'est pas de la paresse, mais de la vraie conscience professionnelle.

Même dans le cas où le retour sur investissement est positif avant qu'on ne quitte le projet, il ne s'agit pas de paresse, mais de productivité.

J'ai l'impression que, en dehors de notre métier, personne ne détourne de la sorte la définition de la paresse. Par exemple, si un étudiant travaille dur pour décrocher un poste qu'il pense être plus tranquille que la moyenne, personne ne qualifiera cet étudiant de « paresseux sur une vision globale de l'ensemble de sa vie ».

Attention au vocabulaire, car cela peut desservir les développeurs. Les non-développeurs ont déjà tendance à croire que tout se code en 5 minutes et que les développeurs qui ne suivent pas ce rythme se tournent les pouces. Si on en rajoute une couche en disant à tort que les bons développeurs sont paresseux, cela risque d'empirer les choses.

[Ryu2000]

Si on en rajoute une couche en disant à tort que les bons développeurs sont paresseux, cela risque d'empirer les choses.

Ça vient d'une citation de Bill Gates (ou c'est une légende urbaine), la traduction a peut être été mal faite : «Je choisirai toujours une personne paresseuse pour faire un travail difficile... Parce qu’il va trouver un moyen facile pour le faire !», «I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.».
Il faut juste bien interpréter le mot "paresseux" dans ce contexte.
Ici paresseux c'est un peu "ingénieux", celui qui va trouver une solution simple à un problème compliqué.

[wazir]

je ne sais pas vraiment s'il y a une similitude avec le sujet actuel, mais une étude sociologique que j'ai lue il y a fort longtemps posait la question suivante : pourquoi existe t il peu de maîtres féminins au jeux d’échecs et pourquoi les femmes étaient peu attirées par ce jeu de réflexion par excellence ( comme l'est l'informatique (pour la réflexion bien sur)) la réponse était que les femmes étaient enclines a faire ce qui est utile même si c'est ennuyeux et que les hommes étaient prédisposés a faire ce qui est ludique et amusant même s'il n y a aucune utilité, ce qui explique aussi l'engouement des garçons pour les jeux video plus que les filles, maintenant pour dire que l'informatique est inutile alors il y a un pas que je ne sauterais pas.