Trolldi : La programmation surpuissante pour les feignants :
Dix concepts qui prouvent que la programmation peut devenir l'affaire des paresseux ?

Le , par Siguillaume, Community Manager
Quelles méthodes utilisez-vous pour soulager votre fardeau de programmeur ?

Programmer c’est rendre la vie facile. De la petite application de gestion à l’intelligence artificielle avancée pour piloter des drones, l’un des objectifs principaux de la programmation est de faciliter la vie des utilisateurs. Mais le programmeur lui-même n’est pas en marge de cette logique. La paresse peut ainsi rapidement paraître comme une vertu du programmeur.

En effet, certaines des méthodes de travail quotidiennement appliquées en programmation, et qui sont d’ailleurs à l’origine de la puissance du code, dans la plupart des cas, sont bien teintées de la marque du paresseux. De celles-ci, nous en relevons dix que sont :

  1. La réutilisation d’un bout de code : le copier/coller est probablement l’une des merveilleuses inventions de l’informatique. Recourir à cette technique est très souvent pratique dans la programmation. Un bout de code qui a fait ses preuves dans un programme peut vite être repris pour gagner du temps.
  2. La programmation sur la base de Framework : en allant sur le principe de ne pas réinventer la roue, les frameworks sont des bibliothèques qui fournissent des modules réutilisables dans la programmation. Aujourd’hui, il en existe plusieurs surtout dans le milieu Web. Et avec le nombre de sites Web bâtis sur des frameworks comme Symfony, il est clair que de nombreux développeurs Web en sont accros.
  3. La déclaration de constante : une constante est une variable qui a une valeur unique dans tout le code. Il permet ainsi au programmeur de ne pas avoir à réécrire plusieurs fois la même valeur, avec des risques d'erreurs.
  4. L’utilisation des procédures et fonctions : en programmation, améliorer la flexibilité d'un code passe, bien souvent, par l'utilisation de procédures et de fonctions qui permettent de simplifier la réutilisation d'une section de code à l'intérieur d'un même programme. En plus, elle offre plus de facilité dans le paramétrage et la gestion des variables.
  5. La notion d’héritage de classe en programmation orientée objet : une classe est une représentation logique d’un objet. Cela dit, plusieurs objets qui partagent des propriétés communes peuvent hériter d'un objet parent, ce qui simplifie la structure globale du code.
  6. L’évaluation paresseuse : aussi appelée évaluation retardée ou appel par nécessité, cette technique consiste à écrire des programmes récursifs pour lesquels l'évaluation d'un paramètre de fonction ne se fait pas avant que les résultats de cette évaluation ne soient réellement nécessaires. Ces résultats, une fois calculés, sont préservés pour des réutilisations ultérieures. Cette technique est généralement utilisée à des fins d'optimisation, pour éviter de calculer un résultat qui pourrait ne pas être utilisé.
  7. L’utilisation du cache : cette pratique est plus utilisée dans la programmation Web. Au lieu de solliciter chaque fois le serveur pour exécuter un programme à plusieurs reprises, on peut permettre la copie de certaines valeurs sur le poste client, pour soulager le serveur. Même si ceci n'allège pas vraiment le travail du programmeur, il présente quand même des avantages sur le long terme dans l'administration du serveur.
  8. L’intégration de l’automation : avec l'avènement des outils de gestion des ressources physiques dans les langages de programmation, les développeurs se trouvent alléger de certaines tâches telles que l'allocation de mémoire. En langage C, par exemple, la fonction malloc permet l'allocation dynamique de mémoire.
  9. La promotion du concept DevOps : avec cette nouvelle approche qui consiste à orienter l'ensemble des efforts des développeurs vers un objectif commun de l'entreprise, les programmes redondants sont vite unifiés, et le travail davantage simplifié. En plus, ce concept orienté vers la méthode agile, exige moins de rigueur dans la programmation de la structure de base.
  10. Le recours abusif aux commentaires dans le code : un code bien structuré est facile à lire. Mais, bien qu'il soit indispensable d'apporter des commentaires sur les sections de son code, certains programmeurs ne s’embarrassent pas des bonnes pratiques de code, ou des efforts à écrire un programme «aéré». Ils écrivent donc de nombreuses lignes de commentaires qui parsèment tout le contenu du programme, pour apporter un supplément d'informations.


Votre avis :
Quelles méthodes utilisez-vous pour soulager votre fardeau de programmeur ?

La rubrique Programmation


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de ensi_en ensi_en - Membre du Club https://www.developpez.com
le 30/09/2016 à 10:31
"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- LarryWall, le concepteur du langage de programmation Perl
Avatar de Shepard Shepard - Membre éprouvé https://www.developpez.com
le 30/09/2016 à 10:45
  • Je ne considère pas la programmation comme un fardeau :p
  • Je passe beaucoup plus de temps à réfléchir sur papier au code que je vais écrire du code qu'à écrire ce code ^^ Qui a une astuce pour que mon bureau cesse de ressembler à la caverne d'ali-baba (mais sans trucs de valeur) ?
Avatar de François DORIN François DORIN - Responsable .NET & Magazine https://www.developpez.com
le 30/09/2016 à 11:02
Bon, c'est trolldi mais quand même

Les points cités ne sont pas vraiment de la paresse. C'est plutôt du bon sens !

S'il fallait 10 citer points de paresse :
  1. Ne pas mettre à jour la documentation suite à la modification d'une API (quand il y en a une !) ;
  2. Mettre en commentaire un TODO, un FIXME etc... et le laisser pour longtemps, très longtemps ;
  3. Ne pas refactoriser son code lorsque c'est nécessaire (il marche, pourquoi y toucher ?) ;
  4. Ne pas mettre à jour les tests ;
  5. Utiliser un langage avec Garbage Collector ;
  6. Masquer un bug au lieu de le corriger (soigner les symptômes au lieu d'en trouver la cause) ;
  7. Ne pas utiliser de système de contrôle de version (commiter, ça prend du temps !) ;
  8. Ou écrire en message de commit "commit" ;
  9. Fusionner les travaux des autres en ne considérant que ses propres modifications (les autres feront le boulot :p) ;
  10. Ne pas traiter les erreurs


A vous de proposer les vôtres
Avatar de benoit1024 benoit1024 - Membre actif https://www.developpez.com
le 30/09/2016 à 11:58
Citation Envoyé par dorinf Voir le message
  1. Ne pas mettre à jour la documentation suite à la modification d'une API (quand il y en a une !) ;
  2. Mettre en commentaire un TODO, un FIXME etc... et le laisser pour longtemps, très longtemps ;
  3. Ne pas refactoriser son code lorsque c'est nécessaire (il marche, pourquoi y toucher ?) ;
  4. Ne pas mettre à jour les tests ;
  5. Utiliser un langage avec Garbage Collector ;
  6. Masquer un bug au lieu de le corriger (soigner les symptômes au lieu d'en trouver la cause) ;
  7. Ne pas utiliser de système de contrôle de version (commiter, ça prend du temps !) ;
  8. Ou écrire en message de commit "commit" ;
  9. Fusionner les travaux des autres en ne considérant que ses propres modifications (les autres feront le boulot :p) ;
  10. Ne pas traiter les erreurs
Cool à mon boulot, on a plus de la moyenne !!
Avatar de RyzenOC RyzenOC - Inactif https://www.developpez.com
le 30/09/2016 à 11:59
tous foutre dans un fichier
ne pas faire de tests
ne pas utiliser de gestionnaire de version, ni aucun logiciels de gestion style Maven, Nexus...
Essayer de faire un maximum de copier-coller sur des bouts de code pomper sur github
ne pas fournir de doc
ne pas mettre de commentaire
quand y'a un bug, le mettre dans un try: moncodebuggé except: pass
Pour les soucis d'optimisation, suffit de gonfler la config minimal requise, pourquoi optimiser quand on peut acheter 16Go de ram pour 20€ ?

mais le plus important : Commencer doucement le matin et pas trop vite le soir, etre bien reposer c'est la base, avec une pause toute les heures pour limiter les risques du métier.
Avatar de Daniel Josue Daniel Josue - Membre régulier https://www.developpez.com
le 30/09/2016 à 12:39
Citation Envoyé par dorinf Voir le message
Bon, c'est trolldi mais quand même
Les points cités ne sont pas vraiment de la paresse. C'est plutôt du bon sens !
A mon avis, il s'agit plutôt de présenter des bonnes pratiques qui font du développeur un potentiel paresseux
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 30/09/2016 à 12:46
Citation Envoyé par Daniel Josue Voir le message
A mon avis, il s'agit plutôt de présenter des bonnes pratiques qui font du développeur un potentiel paresseux
Heu... le copier/coller et plus généralement la duplication de code est très long d'être une bonne pratique...

De même que le recours abusif de commentaires dans le code, quand il faudra modifier le code et qu'on se retrouvera avec des commentaires obsolètes, ça va être une vraie partie de plaisir... Le code est censé déjà être explicite pour être compris, les commentaires à rajouter devraient être rares. À part les commentaires pour doxygen afin de générer une documentation, les autres commentaires devraient être vraiment rares et restreints vraiment à des points précis et ambigus.
Avatar de - https://www.developpez.com
le 30/09/2016 à 13:42
rapid application development, la plus part du temps pour commencer il y a déjà beaucoup de fait, surtout pour le coté design.
Accès aux drivers ou ressources, bases de données relationnelles (SQL) et autres algorithmes des plus simples au plus compliqués...

Atari ST vive la compilation .
Avatar de ZenZiTone ZenZiTone - Membre expert https://www.developpez.com
le 30/09/2016 à 15:19
Citation Envoyé par dorinf Voir le message
Les points cités ne sont pas vraiment de la paresse. C'est plutôt du bon sens !
La paresse ce n'est pas seulement "sur le moment" (cf les TODO, par exemple) mais aussi sur le long terme (j'ai une fonction un peu générique. Je la met dans mon Framework maintenant comme ça j'aurais pas à le faire plus tard..).

Un point de paresse perso : déboguer au Debug.WriteLine C'est de la fausse paresse car, au final, on tape plus de code et on devra forcément passer par un point d'arrêt pour identifier la cause. Mais ça permet de faire moins de "instruction suivante"
Avatar de Glutinus Glutinus - Expert éminent sénior https://www.developpez.com
le 30/09/2016 à 15:25
C'est ironique, car quand bien même on peut critiquer les personnes qui suivent ces points ("ne fais pas de copier coller bête et simple, c'est le meilleur moyen pour oublier qu'il y a quelque chose qui n'est pas adapté pour le point suivant", y en a qui ne pensent pas à factoriser des choses et sont capables de tout réécrire de A à Z parce qu'il fallait mettre le numéro de portable et non du fixe ^^

Citation Envoyé par Siguillaume Voir le message

Votre avis :
Quelles méthodes utilisez-vous pour soulager votre fardeau de programmeur ?
C'est vrai, on est trolldi ?
Je délègue

Nan mais sérieux, je connaissais un tir-au-flanc qui repérait dans la boite quels étaient les petits jeunots qui n'avaient jamais travaillé avant, essayait de refiler ses tâches en disant que c'était une évolution incroyable dans leur carrière ^^
Contacter le responsable de la rubrique Programmation