La programmation en général devient-elle plus facile à lire, à écrire et à comprendre au fur et à mesure de votre expérience? [fermé]

Je suis un débutant en programmation et j'ai lu des livres, étudié, lu des articles, etc. J'obtiens d'excellents résultats depuis que j'ai commencé à apprendre la programmation, et quand j'étais débutant, je pensais tout savoir sur la programmation, mais en apprenant plus, j'ai réalisé à quel point ce domaine est difficile (en fait, tous les domaines sont difficiles, mais ce n'est pas le point).

De nos jours, j'ai écrit un logiciel fonctionnel et j'ai appris les bases de 3 langues et je suis intermédiaire dans une seule langue. Quand je regarde des choses avancées comme MYSQL, la programmation OpenGL ou même le code C ++ de Visual Studio, cela me donne des maux de tête, et même lorsque je visualise le code source HTML de nombreux sites Web (la plupart des codes sources sur les sites Web vus par Google Chrome semblent très désordonnés et non organisés). ) ça me rend confus à la limite de mon cerveau. Tout cela semble simple au début, mais quand je regarde ces choses avancées, je me demande comment on peut apprendre autant.

En bref, la question est de savoir si ces choses deviennent plus claires pour un programmeur à mesure qu’il avance dans sa carrière. Les sujets compliqués comme ceux énumérés ci-dessus (OpenGL, MySQL, sites HTML avancés) deviennent-ils plus faciles à lire, à écrire et à comprendre à mesure que vous en apprenez plus, ou est-ce que cela devient simplement plus compliqué au fur et à mesure? Comment pouvez-vous combattre ce sentiment d'être une fourmi dans le monde de la programmation et que ce truc est le pied sur le point de vous écraser?

Réponse courte: non.

Longue réponse:

Lire le code des autres devient plus facile, oui. Mais seulement lire. À mesure que vous gagnez de l'expérience et des compétences, vos exigences personnelles en tant que développeur grandissent.

• Vous ne voulez pas simplement écrire du code. Vous voulez écrire du beau code .

• Vous ne supposez pas que votre code fonctionne dans des conditions idéales . Vous commencez à penser à toutes les mauvaises choses qui peuvent survenir lors de l’exécution de votre code, à gérer des exceptions, à des problèmes de matériel, à la latence du réseau, et le problème s’aggrave au fur et à mesure de vos compétences.

• Vous ne lisez pas et n'écrivez pas de code dans la seule langue que vous connaissez. En tant que développeur habile, vous savez que pour résoudre ce problème spécifique que vous avez actuellement, la programmation fonctionnelle est une bien meilleure alternative . Vous devez donc maintenant lire et écrire du code dans un langage de programmation fonctionnel.

• Vous ne vous limitez pas à un petit ensemble de bibliothèques que vous connaissez. Si vous codez en C #, vous souhaitez connaître et utiliser toute la puissance de nombreuses bibliothèques de .NET Framework.

• Vous n'utilisez plus le bloc-notes. Vous avez besoin de votre puissant IDE et vous voulez savoir comment coder les tests unitaires, en quoi consistent les métriques de code et quelle est la signification de centaines d'options et de fenêtres que votre IDE peut vous montrer.

• Vous ne voulez pas vous limiter modestement à un ensemble d'outils de base fournis par le langage . En C #, vous souhaitez utiliser des génériques, des contrats de code, des réflexions, un développement événementiel, des aspects fonctionnels avec LINQ, des extensions réactives et une tonne d'autres informations apprises, le tout dans un seul projet, si ces informations vous aident à mieux écrire. code.

• Vous ne commencez pas à écrire du code . Vous passez 80 à 90% de votre temps à définir les besoins , à créer l' architecture de votre application, à écrire des tests unitaires, à rédiger de la documentation, etc., et à peine 10 à 20% de votre temps à écrire du code réel .

• Vous vous souciez de la sécurité . Vous connaissez les problèmes juridiques pouvant survenir avec les données manipulées par vos applications. Vous savez ce qu'est ITIL . Vous connaissez certaines normes ISO et vous les appliquez quotidiennement dans votre travail.

Oui, vous gagnez de l'expérience et des compétences, et il devient plus facile de résoudre un problème donné avec toutes les connaissances et capacités intellectuelles que vous avez acquises. Mais les problèmes que vous devez résoudre grandissent également, et vous n'êtes tout simplement pas enthousiaste à l'idée de résoudre les problèmes du niveau de ceux que j'ai résolus lorsque vous avez commencé à programmer.

En acquérant des compétences, vous aurez également une idée de la complexité du développement logiciel, vous apprendrez des aspects que vous ne pouviez même pas imaginer quand vous commenciez à apprendre la programmation et que vous souhaitez et devez appliquer toutes les choses que vous apprenez quotidiennement.

En bref:

1. Le premier jour où vous commencez à apprendre à programmer, la tâche de lister tous les nombres de 1 à 100 divisibles par deux est très complexe: vous venez d'apprendre à créer des boucles et d'afficher des nombres à l'écran, mais vous ne savez pas comment le nombre est divisible par deux.

2. Dix ans plus tard, le même exercice semble être extrêmement simple. Mais aussi, dix ans plus tard, vous écrivez des applications qui doivent utiliser des transactions, sont hébergées sur plusieurs serveurs et doivent gérer correctement les sessions entre serveurs, et stockent les détails des comptes bancaires de vos clients, avec tous les aspects juridiques et de sécurité qui en résultent.

3. ... Et vous vous demandez "Comment pourrais-je faire cela?" exactement de la même manière que vous le faisiez il y a dix ans, lorsque vous deviez afficher des chiffres sur un écran avec une boucle.

Lorsque tout devient facile pour vous dans un domaine, cela signifie que vous avez atteint la perfection dans ce domaine ou que vous ne vous en souciez plus.

Atteindre la perfection dans un domaine aussi vaste que le développement logiciel est impossible, aussi intelligent que vous soyez.

En tant qu'enfant, vous apprenez à parler puis à lire votre langue maternelle. La mécanique de base est une lutte au début, mais à un moment donné, elle vient couramment. Cependant, vous avez toujours un nombre infini de livres que vous n'avez pas encore lus, et sur certains sujets, vous devez augmenter votre vocabulaire avant de pouvoir comprendre le livre.

Il en va de même pour la programmation informatique. À un moment donné, la langue elle-même cesse de se sentir comme une langue étrangère, mais il reste encore beaucoup de choses écrites dans cette langue que vous ne connaissez pas encore. Mais tout vous est accessible avec quelques efforts.

Certains travaux de programmation sont très répétitifs et consistent essentiellement à ré-implémenter des logiciels très similaires pour différents clients. Dans ces emplois, vous pourriez avoir l'impression d'être sur un plateau d'apprentissage. Dans d’autres emplois, vous faites constamment quelque chose de nouveau et d’exceptionnel et vous n’arrêtez jamais d’apprendre de nouvelles choses.

Il y a déjà de très bonnes réponses ici, mais j'ai pensé ajouter quelques points supplémentaires:

Quand j'étais débutant, je pensais tout savoir sur la programmation, mais en apprenant plus, j'ai réalisé à quel point ce domaine est difficile.

C'est ce qu'on appelle l'effet Dunning-Kruger . Il est extrêmement courant parmi les programmeurs débutants et, en fait, les débutants dans de nombreux domaines.

La plupart des codes sources sur les sites Web, vus par Google Chrome, semblent très désordonnés et non organisés.

Les auteurs de ces sites Web souhaitaient-ils que vous puissiez les comprendre? Probablement pas. Il est dans leur intérêt d'avoir un code difficile à comprendre.

je me demande simplement comment on peut apprendre autant.

En se spécialisant . Je suis un expert dans un domaine extrêmement restreint: la conception et la mise en oeuvre d'analyseurs sémantiques du compilateur C #. Si j'avais passé quinze ans à étudier OpenGL, XML, HTML, etc., je serais un expert en la matière et mystifié par les analyseurs sémantiques. Mais je ne l’ai pas fait et je n’ai donc qu’une connaissance très élémentaire d’OpenGL, XML et HTML.

En bref, la question est de savoir si ces choses deviennent plus claires pour un programmeur à mesure qu’il avance dans sa carrière.

Oui, parce que vous commencez à voir les grands modèles. Prenez OpenGL par exemple. Vous avez probablement déjà vu un tas de "bibliothèques API" - de gros morceaux de code lié où vous vous connectez avec le code en appelant un tas de fonctions nommées avec des arguments particuliers. Et vous pouvez obtenir une compréhension de base d'OpenGL simplement en comprenant que c'est une API.

Lorsque vous avez acquis plus d'expérience et que vous avez observé différentes techniques de programmation, vous vous rendez compte que des technologies apparemment sans rapport, comme OpenGL et LINQ en C #, ont des points communs. Les deux sont des API dans lesquelles vous créez des flux de travail qui canalisent des données et que vous pouvez exécuter des optimiseurs et d'autres transformations sur le flux de travail de manières riches et intéressantes. Une fois que vous avez ce concept dans votre boîte à outils, il devient soudainement beaucoup plus facile d'exploiter toute la puissance de toute API qui utilise ce modèle.

Les sujets compliqués comme ceux énumérés ci-dessus (OpenGL, MySQL, sites HTML avancés) deviennent-ils plus faciles à lire, à écrire et à comprendre à mesure que vous en apprenez plus, ou est-ce que cela devient simplement plus compliqué au fur et à mesure?

Ils deviennent à la fois plus faciles et plus compliqués. Plus facile parce que, comme je l'ai dit, vous commencez à reconnaître les schémas de pensée plus larges qui sous-tendent la conception du système, ce qui vous permet de l'utiliser plus efficacement. Plus compliqué parce que vous pouvez maintenant utiliser le système pour résoudre des problèmes plus compliqués , et vous commencez alors à rencontrer les limites du système.

Comment pouvez-vous combattre ce sentiment d'être une fourmi dans le monde de la programmation et que ce truc est le pied sur le point de vous écraser?

Vous êtes une fourmi; nous sommes tous des fourmis. Mais ce n’est pas le pied qui vous écrase; C’est le monde que vous explorez, vivez, profitez et améliorez. Vous, fourmis, ne pouvez explorer qu'une infime partie de celle-ci. Choisissez une partie que vous aimez où vous pouvez ajouter une valeur réelle et devenez un expert.

Réponse courte, oui.

Avec le temps et l'exposition, ces choses deviennent plus faciles à comprendre.

N'oubliez pas que lorsque vous consultez des sites à partir des outils de développement de votre navigateur, ils sont souvent générés par un framework. Que ce soit n'importe quel nombre de choses ... ASP.NET, JSP, RoR, Django, ... qui sait. Certains de ces frameworks produisent un code plus propre que d'autres.

En terminant ... l'exposition mène à la compétence. Il n'y a aucun moyen d'écraser ce sentiment. Juste l'expérience et l'apprentissage. Il faut du temps pour s'y installer, acquérir des connaissances sur le domaine et apprendre les compétences utilisées par votre environnement.

Je suis d’accord avec certaines des réponses déjà données, mais je pense qu’il s’agit également d’un point sous-jacent qui n’est pas abordé au sujet de la lecture de code. Quand j'ai commencé à regarder du code open source, cela semblait écrasant et énorme. Mais devinez quoi? ça va toujours être énorme. À un moment donné, vous réalisez que vous êtes mieux à même d'extraire ce que vous voulez savoir et d'aller de l'avant.

Un exemple que vous avez donné concernait un groupe de code HTML:

Pourquoi regardez-vous le code HTML? Probablement pas parce que vous voulez apprendre le code HTML de tout le site. Il y a probablement une astuce spécifique que vous espérez comprendre. Dans ce cas, il suffit de trouver le code HTML approprié avec un outil tel que firebug.

Si vous voulez vraiment savoir comment tout le site est créé, vous vous êtes rendu compte que le rendu HTML n'était pas la solution. Vous feriez mieux de regarder un projet open source utilisant une technologie similaire. Cependant, essayer d'apprendre le code d'un projet entier ne vaut pas la peine que cela puisse paraître. C'est ennuyeux, prend du temps, il est facile d'oublier ce que vous avez appris et vous n'avez rien à montrer à la fin. Vous apprendrez moins en lisant le code des autres peuples sans fin et beaucoup plus en utilisant des éléments spécifiques et intéressants de celui-ci pour écrire des plug-ins, des ajouts de fonctionnalités ou des échafaudages et des conseils pour vos propres projets.

Essayez d'apprendre le minimum absolu pour obtenir quelque chose de votre propre travail. Ne revenez à vos points de référence que lorsque vous êtes bloqué ou que vous souhaitez apprendre quelque chose de nouveau. Cela va à l’encontre de certaines idées reçues selon lesquelles il faut tout comprendre sinon vous programmez dans le noir. Mais finalement, vous réalisez que cet objectif est impossible et que vous apprenez à équilibrer les objectifs de tout savoir et de terminer le travail sur lequel vous travaillez.

La réponse courte est OUI mais cela dépend en grande partie de la définition de l'expérience.

Je pense qu'il y a au moins 3 parties dans le développement. À mesure que vous vous améliorez à chaque segment, certaines choses deviennent plus claires.

1. Comprendre les exigences commerciales . Cela vous donne une meilleure vue d'ensemble de l'application. Mieux vous comprendrez pourquoi les règles métier sont ce qu'elles sont, plus vite vous comprendrez pourquoi certaines choses sont faites d'une certaine manière. Par exemple, vos clients doivent se conformer à la réglementation gouvernementale X, raison pour laquelle ils doivent préparer le document Y, raison pour laquelle ils ont besoin de conserver ces informations apparemment inutiles.

2. Comprendre les exigences TECHNIQUES . C'est comme # 1 sauf qu'il s'agit plus de comprendre pourquoi au niveau technique. Certains outils et technologies ont leurs propres inconvénients, jusqu'à ce que vous les ayez traitées avant qu'il soit difficile de comprendre pourquoi les choses sont faites d'une certaine manière. Ceci est plus évident lorsque vous traitez avec des systèmes hérités. Par exemple, l'application utilise un bus de service particulier qui utilise uniquement XML.

3. Comprendre les exigences de la langue . Comme d’autres l’ont mentionné, plus vous maîtrisez une langue, plus vous pourrez lire rapidement ce que le codeur original tentait de réaliser. Pourtant, sans les N ° 1 et N ° 2, vous constaterez que cette capacité accrue atteint un pic assez rapidement.

Essayez de vous impliquer dans plusieurs aspects du développement, car cela ne deviendra vraiment pas plus facile tant que vous n’aurez pas fait tous les domaines au moins quelques fois.

Rappelez-vous que la perfection (et le but) du code de quelqu'un d'autre sont toujours relatifs aux n ° 1 et n ° 2. Ce sont les principaux facteurs expliquant la raison pour laquelle le code est dans l'état dans lequel il se trouve. Les changements fréquents dans ces deux domaines sont la principale raison pour laquelle nous obtenons du code spaghetti tout le temps. Ainsi, à moins que vous ne sachiez lire les exigences commerciales et techniques, la lecture du code sera toujours un PITA royal.

Cela devient plus facile et plus compliqué en même temps!

Connaître les autres, c'est la sagesse.
Connaître le soi, c'est l'illumination.
Maîtriser les autres nécessite de la force;
La maîtrise de soi nécessite de la force;
Celui qui sait qu'il en a assez est riche.
La persévérance est un signe de volonté.
Celui qui reste où il est endure.
Mourir mais ne pas périr, c'est être éternellement présent.

traduit en développement logiciel

Savoir beaucoup de technologies, c'est de la sagesse. (Tout provient d'ALGOL)
Savoir ce que vous ne savez pas, c'est l'illumination. (LISP)
Maîtriser de nombreux langages, frameworks et plates-formes nécessite beaucoup d'efforts. (Java)
Maîtriser uniquement ce que vous devez savoir et uniquement ce qui nécessite de la force. (et Google ou stackoverflow.com) Il est important de
savoir quand arrêter de coder et livrer quelque chose. (Pas d'analyse paralysie ou plaquage or)
Continuez à travailler pour ce que vous essayez d'atteindre, cela demande de la concentration et de la volonté. (Tout change constamment, vous n'êtes jamais fini)
Utilisez une ou deux technologies pour endurer. (Le COBOL paye toujours bien, tout comme le C)
Quitter la programmation et entrer dans la gestion, c'est être éternellement présent. (ou laissez un héritage du logiciel FOSS que tout le monde continuera à utiliser bien après votre mort).

En bref, la question est de savoir si ces choses deviennent plus claires pour un programmeur à mesure qu’il avance dans sa carrière. Les sujets compliqués comme ceux énumérés ci-dessus (OpenGL, MySQL, sites HTML avancés) deviennent-ils plus faciles à lire, à écrire et à comprendre à mesure que vous en apprenez plus, ou est-ce que cela devient simplement plus compliqué au fur et à mesure? Comment pouvez-vous combattre ce sentiment d'être une fourmi dans le monde de la programmation et que ce truc est le pied sur le point de vous écraser?

Je vais adopter une approche légèrement différente de celle des autres répondants. Je crois que la lecture et l'écriture de code deviennent en fait plus faciles à mesure que vous le faites plus, et je vais le démontrer avec une simple analogie.

Pensez au moment où vous avez commencé à faire du sport. Au tout début avec le premier sport que vous avez appris, la coordination de base pour les tâches simples d’un sport individuel semblait probablement très difficile. En devenant un peu plus expérimenté, vous avez commencé à maîtriser les tâches simples pour ne plus avoir à y penser et vous avez remarqué qu'il y avait des tâches plus complexes auxquelles vous pouviez faire attention (comme regarder les autres joueurs pour prédire leur comportement).

Ensuite, lorsque vous vous êtes essayé à un autre sport, vous avez probablement constaté que vous n'étiez pas si loin derrière lorsque vous avez commencé. Attraper un ballon de basket est très différent d’attraper un ballon de baseball, mais une personne qui maîtrise l’une d’elles aura beaucoup plus de facilité à attraper l’autre qu’une personne qui n’a jamais fait l’une auparavant. Fort de votre expérience dans la pratique d’un second sport, vous avez découvert que le premier sport vous donnait des compétences à la fois spécifiques et génériques . Les compétences spécifiques (attraper un ballon de basket) ne sont utiles que dans leur domaine, mais les compétences génériques (suivre un objet qui se déplace rapidement, approcher dans un espace tridimensionnel et élaborer un plan pour y faire face) vous rendent meilleur dans tous les domaines connexes.

Qu'est-ce que cela a à voir avec la programmation? La première ligne de code que vous lisez vous expose à un monde construit sur certaines règles. Vous avez appris ces règles (la syntaxe et les idiomes de cette langue) sous forme de compétences spécifiques, mais vous avez également acquis des compétences génériques utiles: comprendre le fonctionnement interne des ordinateurs et savoir exprimer ses intentions de la manière dont un ordinateur peut le comprendre. Chaque nouvelle langue que vous apprenez vous donne de nouvelles compétences spécifiques, mais elle renforce également vos compétences génériques et vous aide à voir les schémas gravés dans tous les langages informatiques, tels que les dépôts minéraux situés le long d'un mur de canyon. Une fois que vous vous êtes vraiment familiarisé avec quelques langues différentes, vous commencez à être capable de reconnaître la "forme" de la plupart des codes, si vous pardonnez le flou, même si vous ne connaissez rien à la langue dans laquelle il est écrit.

Par exemple, les trois langages que vous avez mentionnés (MYSQL, OpenGL, C ++) ont des caractéristiques communes:

• Il est possible de calculer séparément de petites parties d'un algorithme et de les composer ultérieurement en solution complète
• L’ordinateur nécessite généralement une certaine préparation générale avant de pouvoir commencer à travailler sur votre problème spécifique (création d’un tableau, initialisation d’un canevas ou chargement de bibliothèques communes).
• Les instructions précédentes ont priorité et affectent les instructions ultérieures, c’est-à-dire que l’ordinateur commence en haut du code et s’efface vers le bas.

Plus vous programmez, plus vous vous rendrez compte que, quelle que soit la forme de la balle, il ne s'agit que d'une balle qui vient vers vous et vous savez quoi en faire sans trop y penser. Toute la programmation consiste à tenter d'exprimer vos intentions de manière à ce que l'ordinateur puisse comprendre; apprenez suffisamment et vous commencerez à lire les intentions au lieu du code.

PS: chaque fois que vous commencez à vous sentir comme si vous connaissiez votre chemin, vous tomberez sur quelque chose qui vous brise le cerveau et vous fait sentir comme un débutant. C'est ce que nous aimons dans ce métier, il y a toujours quelque chose de nouveau à apprendre.

Réponse courte: oui , en général

Cependant, vous ne deviendrez pas un spécialiste si vous généralisez. Devenir un spécialiste signifie également réaliser toutes les choses que vous ne savez pas: cela peut être un sentiment accablant.

En progressant dans le temps, vous gagnez de l'expérience.

Au fur et à mesure que vous avancez dans le temps, d'autres langages / modèles, etc. se développent parallèlement à votre développement.

Une autre variable à votre question est si vous acquérez une expérience significative par rapport à l’industrie, car elle évolue également dans le même temps constant. L'industrie de la technologie est une cible mouvante et contrairement à la plupart des autres industries.

Une bonne question pourrait également être: est-ce que vous vous épandez trop ou trop lourdement dans une langue donnée?

C’est une source inépuisable d’émerveillement (et d’angoisse) du nombre de langages informatiques et de leur évolution constante. Ajoutez à cela le nombre de frameworks différents dans chaque langue et, pour chaque framework, la vaste gamme de bibliothèques et de plug-ins disponibles. Ajoutez à cela le nombre d'éditeurs de code et d'EDI.

Toutes ces variations ont deux dimensions de complexité.

1. Leur vocabulaire et leur syntaxe sont différents.
2. Les abstractions (concepts de haut niveau) qu’ils supportent diffèrent.

Ils ont aussi une chose en commun. Turing complète. Avec assez d'effort de la part d'un programmeur, ils peuvent tous être utilisés pour résoudre tous les problèmes! Donc, si vous commencez avec un langage comme le C (petit vocabulaire, syntaxe complexe et presque aucune abstraction), vous aurez certainement l’impression que vous pouvez faire quelque chose (à juste titre).

Basculez ensuite vers "des éléments faciles" tels que CSS, HTML, Javascript et peut-être aussi des frameworks tels que Bootstrap et React, et votre cerveau frissonnera - comme le ferait Albert Einstein. Les gens pensent "je connais le français, apprendre l’allemand devrait donc être facile". Non!

De nombreuses abstractions de programmation peuvent être apprises à partir de modèles logiciels . Plusieurs livres sont consacrés à ce sujet. Les modèles sont partout, sont agnostiques en langues et peuvent être appris et compris une fois . Si vous connaissez vos modèles, vous pouvez les utiliser dans n’importe quelle langue et les reconnaître lorsqu’ils sont construits dans des langues et plus fréquemment dans divers cadres.

La plupart des gens mettent un à deux ans à maîtriser une nouvelle langue et les employeurs le savent. C'est pourquoi ils n'embauchent pas de personnes qui ne connaissent pas bien leur langue, car le nouvel employé passera beaucoup de temps à lutter avec la langue et pas assez de temps à résoudre les problèmes de l'entreprise.

En résumé, les principes / abstractions informatiques, les modèles de logiciels et le type de problèmes professionnels que vous rencontrez changent lentement. Vous pouvez apprendre une fois et accumuler de nouvelles connaissances progressivement. Inversement, les langages informatiques, les frameworks, appelés "écosystèmes" et les bibliothèques de composants changent très rapidement, de même que tous les outils qui les entourent. Attendez-vous à ce que le rythme d'apprentissage soit lent et prend du temps!

Les sujets compliqués comme ceux énumérés ci-dessus (OpenGL, MySQL, sites HTML avancés) deviennent-ils plus faciles à lire, à écrire et à comprendre à mesure que vous en apprenez plus, ou est-ce que cela devient simplement plus compliqué au fur et à mesure? Comment pouvez-vous combattre ce sentiment d'être une fourmi dans le monde de la programmation et que ce truc est le pied sur le point de vous écraser?

Lorsque des progrès sont réalisés, nous désapprenons et apprenons à nouveau ce que nous pensions savoir auparavant. - Henry David Thoreau

Il y a une histoire du maître zen et de la tasse de thé débordante .

Parfois, nous devons abandonner nos idées préconçues et nos opinions du passé pour pouvoir nous permettre d’apprendre de nouveaux concepts.

Rappelez-vous: si vous vous sentez dépassé par un nouveau concept, vous devez rechercher de nombreux enseignants.

Récemment, lorsqu’on m'a confié la tâche de mettre à jour un logiciel interne de la société utilisant un langage de script, je ne connaissais pas bien le logiciel. Au début, c'était très stressant. Cependant, après avoir changé d'attitude, j'ai commencé à trouver des ressources expliquant la syntaxe et les concepts de base. J'ai terminé le projet et utilise maintenant ce langage de script comme l'un de mes outils pour faire plus de choses.

Votre attitude fait toute la différence.