Trolldi : La programmation surpuissante pour les feignants

Trolldi : La programmation surpuissante pour les feignants
Dix méthodes de travail qui prouvent que la programmation peut vite devenir l’affaire des paresseux ?

Pièce jointe 221539

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 :
:fleche: Quelles méthodes utilisez-vous pour soulager votre fardeau de programmeur ?


:fleche: La rubrique Programmation

"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

• 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) ? :D

Bon, c'est trolldi mais quand même :D

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 :mouarf: ;
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 ;)

Citation:

---

Envoyé par dorinf

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 :mouarf: ;
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 !! :mrgreen::roll:8O:(

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.

Citation:

---

Envoyé par dorinf

Bon, c'est trolldi mais quand même :D
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 :aie:

Citation:

---

Envoyé par Daniel Josue

A mon avis, il s'agit plutôt de présenter des bonnes pratiques qui font du développeur un potentiel paresseux :aie:

---

Heu... le copier/coller et plus généralement la duplication de code est très long d'être une bonne pratique... :aie:

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.

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 :ptdr: vive la compilation :mouarf:.

Citation:

---

Envoyé par dorinf

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 :aie: 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" :mrgreen:

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

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

---

C'est vrai, on est trolldi ?
Je délègue :mouarf:

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 ^^

L'abus de prestataire. Cela soulage grandement mon fardeau. Par exemple, on est vendredi, il est 16h, je viens de leur envoyer une demande urgente à traiter avant lundi 8h, ça m'a grandement soulagé mon week-end!

En plus, c'est pratique, le presta, il peut rien dire à part "oui" et "tout de suis maître".

La paresse est une vertu : il s'agit d'en faire le plus possible en dépensant le moins d'énergie.

En physique, on appelle ça le principe de moindre action. A la fac, je m'en étais servi pour démontrer à un prof pourquoi il est naturel que les étudiants s'assoient le plus au fond possible d'un amphi. :mrgreen:

Citation:

---

Envoyé par Siguillaume

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

---

Je vais sur developpez.net :aie:

Citation:

---

Envoyé par Grogro

En physique, on appelle ça le principe de moindre action. A la fac, je m'en étais servi pour démontrer à un prof pourquoi il est naturel que les étudiants s'assoient le plus au fond possible d'un amphi. :mrgreen:

---

A la place du prof, j'aurai acquiescé et j'aurai tiré fait tirer aux étudiants leur note de partiel aux dès (toujours le principe de moindre action) et pour le second semestre j'aurai probablement donné comme projet de fin d'année un programme de répartition de notes réaliste se basant sur les cours d'inférence bayésienne donné par un collègue vers lequel j'aurai orienté mes étudiants afin de libérer de précieuses heures pendant lesquelles je donnerai des instructions à des farmers chinois pour qu'il me fasse l'équipement complet de mon perso dans le meilleur MMORPG du moment. Perso jouer par mon fils que j'aurai probablement fait faire par un pote.
Il va sans dire que j'utiliserai le meilleurs projets pour noter mes élèves. Je m’assurerai quand même de donner la meilleure note au meilleur projet histoire de ne pas être trop chien et de les motiver...

Mine de rien. Ne rien faire, ça use !

Principe que je répète souvent dans mes stages : ne pas confondre fainéantise et paresse :

- le fainéant cherche à ne rien faire et du coup, se trouve souvent à faire plus de boulot par la suite. Exemple : j'ai la flemme d'écrire une fonction pour factoriser mon code, donc je fais des copier-coller. Donc, en cas de modification plus tard, je me retrouve avec plus de boulot (modifier partout mon code), ou -pire- des bugs parce que j'ai eu la flemme de de modifier l'ensemble du code collé.
Cela s'applique à des tas de contexte : j'ai la flemme de nettoyer la table après manger, donc les taches sèchent, du coup quand je dois la nettoyer, je dois frotter davantage. Et si je ne nettoie pas, je me retrouve avec des 'tites bestioles et/ou une odeur de moisi...

- le paresseux est qqu'un qui est capable de réfléchir pendant 1h pour ne pas travailler 5min (c'est une définition toute personnelle). Il s'ensuit que, à force d'utiliser son cerveau, le paresseux est bien souvent plus intelligent que la moyenne. Ainsi, il va utiliser tout ou partie des solutions évoquées dans l'article, dès qu'il pense que cela lui économisera de l'effort. Si je reprends l'exemple de la table ci-dessus, le paresseux utilisera un plateau, plus facile à nettoyer ;)

Yvan

Il ne faut pas confondre la paresse et la fainéantise.

Le fainéant va bâcler le boulot parce qu'il s'en fout de bien bosser, il veut juste se débarrasser d'une tâche : copier-coller, pas de tests, etc.

Le paresseux va s'organiser pour que le travail soit fait au prix du moindre effort : factorisation, framework, etc.

La paresse est en fait une vertu.

[edit finalement j'ai dit pratiquement la même chose que dans le précédent message]

Concernant l'utilisation du cache, ce n'est pas tellement du côté du navigateur que ça se passe à mon sens. Plutôt côté serveur, avec des requêtes concernant des pages (ou élément de pages) statiques servis directement depuis le cache (Varnish et consorts).

Et même carrément coté DB avec des résultats de requête cachés lorsqu'il n'y a pas eu d'écriture sur les tables entre deux lectures, ou un truc du genre.

Mais là ça n'a plus grand chose à voir avec de la flemme, vu la complexité des mécanismes mis en œuvre…

A mon avis , c'est des techniques et des bons pratiques qui ont participer a la revolution au niveau programmation

Bonjour à tous.
Lorsqu'on est paresseux, on n'est pas feignant mais fainéant...

On peut aller très loin, mais tout est question d'interprétation.


L'Académie française.

Le feignant fait semblant (feindre).
Le fainéant ne fait rien (fait néant).

On peut feindre et ne rien produire (s'enfermer dans son bureau).

Les deux termes sont dans le champ de la paresse.

Dans tous les cas, il n'y a pas de goût à l'effort. Rien ne dit que le paresseux peut se réveiller pour inventer la roue ou la brouette dans un gain d'effort futur.