La programmation en général devient-elle plus facile à lire, à écrire et à comprendre à mesure que vous acquérez de l'expérience?
Je suis un débutant en programmation et j'ai lu des livres, étudié, lu des articles et ainsi de suite. J'obtiens d'excellents résultats depuis que j'ai commencé à apprendre la programmation, et quand j'étais débutant, je pensais que je savais tout sur la programmation, mais en apprenant davantage, 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 des logiciels fonctionnels 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, ou la programmation OpenGL, ou même le code Visual Studio C++, 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 source sur les sites Web, vu par google chrome semble très désordonné et non organisé), cela me rend confus jusqu'à la limite de mon cerveau. Tout cela semble simple au début, mais quand je regarde ces choses avancées, je me demande simplement comment on peut apprendre autant.
La question, en un mot, est de savoir si ces choses deviennent plus claires pour un programmeur alors 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 au fur et à mesure que vous en apprenez plus, ou est-ce que cela devient plus compliqué au fur et à mesure? Comment pouvez-vous combattre ce sentiment que vous êtes 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.
Réponse longue:
La lecture du code des autres devient plus facile, oui. Mais seulement la lecture. Au fur et à mesure que vous acquérez de l'expérience et des compétences, vos besoins personnels en tant que développeur augmentent.
Vous ne voulez pas simplement écrire du code. Vous voulez écrire beau code.
Vous ne supposez pas que votre code s'exécute dans conditions idéales. Vous commencez à penser à toutes les mauvaises choses qui peuvent se produire lors de l'exécution de votre code, gérez les exceptions, pensez aux problèmes matériels, à la latence du réseau et le problème augmente à mesure que vos compétences se développent.
Vous ne lisez 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 voulez 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 tester le code unitaire, quelles sont les mesures 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 modestement limitez-vous à un ensemble d'outils de base que la langue vous donne. En C #, vous souhaitez utiliser les génériques, les contrats de code, la réflexion, le développement piloté par les événements, les aspects fonctionnels avec LINQ, les extensions réactives et une tonne d'autres choses que vous avez apprises, le tout dans un seul projet, si ces choses vous aident à mieux écrire code.
Vous ne commencez pas à écrire du code. Vous passez de 80 à 90% de votre temps collecte des exigences, création de architecture de votre application, rédaction de tests unitaires, rédaction de documentation, etc., et seulement 10 à 20% de votre temps pour écrire du code réel.
Vous vous souciez de sécurité. Vous connaissez les problèmes juridiques qui peuvent survenir avec les données manipulées par vos applications. Vous savez ce qu'est ITIL . Vous en connaissez normes ISO et vous les appliquez quotidiennement dans votre travail.
Oui, vous acquérez 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 les 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.
Tout en acquérant des compétences, vous obtenez également un aperçu de la complexité du développement logiciel, apprenez les aspects que vous ne pouviez même pas imaginer lorsque vous avez commencé à apprendre la programmation, et vous voulez et devez appliquer toutes les choses que vous apprenez quotidiennement.
En bref:
Le premier jour où vous commencez à apprendre à programmer, la tâche de lister tous les nombres de 1 à 100 divisible par deux est très complexe: vous venez d'apprendre à faire des boucles et à afficher des nombres à l'écran, mais vous ne savez pas comment trouver si le nombre est divisible par deux.
Dix ans plus tard, le même exercice semble 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 l'état de la session entre les serveurs, et stockent les détails du compte bancaire de vos clients, avec tous les aspects juridiques et de sécurité qui en résultent.
... Et vous vous demandez "comment pourrais-je faire ça?" exactement comme vous l'avez fait il y a dix ans lorsque vous deviez afficher des nombres sur un écran avec une boucle.
Lorsque tout vous devient facile 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 de logiciels est impossible, quelle que soit votre intelligence.
Enfant, vous apprenez à parler puis à lire votre langue maternelle. La mécanique simple de celui-ci est un combat au début, mais à un moment donné, cela vient couramment. Cependant, vous avez toujours une réserve infinie de livres que vous n'avez pas lus, et sur certains sujets, vous devez d'abord augmenter votre vocabulaire juste pour pouvoir comprendre le livre.
Il en va de même pour la programmation informatique. À un moment donné, la langue elle-même cesse de ressembler à une langue étrangère, mais il y a encore beaucoup de choses écrites dans cette langue que vous ne connaissez pas encore. Mais tout vous est accessible avec un certain effort.
Certains travaux de programmation sont très répétitifs, réimplémentant essentiellement des logiciels très similaires pour différents clients. Dans ces emplois, vous pourriez avoir l'impression d'avoir atteint un plateau d'apprentissage. Pour d'autres tâches, vous faites constamment quelque chose de nouveau et d'unique, et ne cessez jamais d'apprendre de nouvelles choses.
Il y a déjà de très bonnes réponses ici, mais j'ai pensé ajouter quelques petits points supplémentaires:
quand j'étais débutant, je pensais tout savoir sur la programmation, mais en apprenant davantage, j'ai réalisé à quel point ce domaine est difficile
C'est ce qu'on appelle effet Dunning-Kruger . Il est extrêmement courant chez les programmeurs débutants, et en fait, les débutants dans de nombreux domaines.
La plupart des codes source sur les sites Web, vus par google chrome semblent très désordonnés et non organisés
Les personnes qui ont écrit ces sites Web voulaient-elles que vous puissiez les comprendre? Probablement pas. Il est dans leur intérêt d'avoir un code difficile à comprendre.
ça me fait juste me demander comment on peut apprendre autant.
Par spécialisation . Je suis expert dans un domaine extraordinairement étroit: la conception et l'implémentation d'analyseurs sémantiques de compilateurs C #. Si j'avais passé quinze ans à étudier OpenGL ou XML ou HTML ou autre, je serais un expert en la matière et mystifié par les analyseurs sémantiques. Mais je ne l'ai pas fait, et donc je n'ai qu'une compréhension très basique d'OpenGL, XML et HTML.
La question, en un mot, est de savoir si ces choses deviennent plus claires pour un programmeur alors qu'il avance dans sa carrière.
Oui, car vous commencez à voir les motifs les plus grands. Prenons OpenGL par exemple. Vous avez probablement vu un tas de "bibliothèques API" - de gros morceaux de code connexe où la façon dont vous vous connectez avec le code est 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 qu'il s'agit d'une API.
Lorsque vous avez acquis plus d'expérience et vu un tas de techniques de programmation différentes, vous vous rendez compte que les technologies apparemment sans rapport - disons, OpenGL et LINQ en C # - ont des points communs. Les deux sont des API où vous créez des workflows qui canalisent les données et que vous pouvez exécuter des optimiseurs et d'autres transformations sur le workflow de manière riche et intéressante. 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 au fur et à mesure que vous en apprenez plus, ou est-ce que cela devient 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 d'utiliser le système plus efficacement. Plus compliqué car 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 que vous êtes une fourmi dans le monde de la programmation et que ce truc est le pied sur le point de vous écraser?
Tu es une fourmi; nous sommes tous des fourmis. Mais ce n'est pas le pied qui vous écrase; c'est le monde que vous pouvez explorer, vivre, bénéficier et améliorer. Vous, fourmi, ne pouvez en explorer qu'une toute petite partie. Choisissez une pièce que vous aimez où vous pouvez ajouter une valeur réelle et devenir un expert en la matière.
Réponse courte, oui.
Avec le temps et l'exposition, ces choses deviennent plus faciles à comprendre.
N'oubliez pas que lorsque vous regardez des sites à partir des outils de développement de votre navigateur, ils sont souvent générés par un framework. Que ce soit un certain nombre de choses ... ASP.NET, JSP, RoR, Django, ... qui sait. Certains de ces cadres produisent un code plus propre que d'autres.
En conclusion ... l'exposition mène à la compétence. Il n'y a aucun moyen d'annuler ce sentiment. Juste l'expérience et l'apprentissage. Il faut du temps pour emménager, acquérir des connaissances dans le domaine et acquérir les compétences que votre environnement utilise.
Je suis d'accord avec certaines des réponses déjà données mais je pense qu'elles sont également un point sous-jacent qui n'est pas discuté de la lecture du 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 vous rendez compte que vous êtes mieux à même d'extraire ce que vous voulez spécifiquement savoir et de continuer.
Un exemple que vous avez donné concernait un tas de code HTML, cependant:
Pourquoi regardez-vous du code HTML? Probablement pas parce que vous voulez apprendre le HTML de tout le site. Il y a probablement une astuce spécifique que vous espérez ramasser. Dans ce cas, il suffit de trouver le code HTML approprié avec un outil comme Firebug.
Si vous voulez vraiment savoir comment l'ensemble du site est créé, vous avez réalisé que le HTML rendu n'est pas la façon de le faire. Vous feriez mieux de regarder un projet open source utilisant une technologie similaire. Cependant, essayer d'apprendre le code d'un projet entier n'est pas aussi valable qu'il y paraît. C'est ennuyeux, long, facile d'oublier ce que vous avez appris, et vous n'avez rien à montrer à la fin. Vous apprendrez moins de lire le code des autres sans fin et bien plus encore en utilisant des morceaux spécifiques et intéressants pour écrire des plugins, des ajouts de fonctionnalités ou comme é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 une nouvelle chose spécifique. Cela va à l'encontre d'une certaine sagesse conventionnelle selon laquelle vous devez tout comprendre, sinon vous programmez dans le noir. Mais finalement, vous réalisez que l'objectif est impossible et vous apprenez à équilibrer les objectifs de tout savoir et l'objectif de réellement terminer ce sur quoi vous travaillez.
La réponse courte est OUI mais cela dépend en grande partie de la façon dont vous définissez l'expérience.
Je pense qu'il y a au moins 3 parties au développement. À mesure que vous vous améliorez à chaque segment, certaines choses deviennent plus claires.
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, c'est pourquoi ils doivent préparer le document Y, c'est pourquoi ils ont besoin que ces informations apparemment inutiles soient stockées.
Comprendre les exigences TECHNIQUES. C'est comme # 1, sauf qu'il s'agit de comprendre pourquoi au niveau technique. Certains outils et technologies ont leurs propres bizarreries, jusqu'à ce que vous les ayez traités avant qu'il soit difficile de comprendre pourquoi les choses sont faites d'une certaine manière. Cela est plus apparent lorsque vous traitez avec des systèmes hérités. Par exemple. L'application utilise un bus de service particulier qui ne prend que XML.
Comprendre les exigences de LANGUE. Comme d'autres l'ont mentionné, plus vous êtes expérimenté avec une langue, plus vite vous pouvez lire ce que le codeur original essayait de réaliser. Pourtant, sans # 1 et # 2, vous constaterez que cette capacité accrue culmine assez rapidement.
Essayez d'être impliqué dans plusieurs aspects du développement, car cela ne devient vraiment pas plus facile tant que vous n'avez pas fait tous les domaines au moins quelques fois.
N'oubliez pas que la perfection (et le but) dans le code de quelqu'un d'autre est toujours relative à # 1 et # 2. Ce sont les principaux facteurs expliquant pourquoi le code est dans l'état où il se trouve. Des changements fréquents dans ces deux domaines sont la principale raison pour laquelle nous obtenons du code spaghetti tout le temps. Donc, à moins que vous ne sachiez lire les exigences commerciales et techniques, la tâche de lire le 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 est l'illumination.
Maîtriser les autres requiert 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
Connaître beaucoup de technologies, c'est de la sagesse. (Tout descend d'ALGOL)
Savoir ce que vous ne savez pas, c'est l'illumination. (LISP)
La maîtrise de nombreux langages, frameworks et plateformes demande beaucoup d'efforts. (Java)
Maîtriser uniquement ce que vous devez savoir et cela ne demande que de la force. (et Google ou stackoverflow.com)
Savoir quand arrêter de coder et livrer quelque chose, c'est quand on sait assez bien. (Aucune analyse de paralysie ou de placage d'or)
Continuez à travailler sur ce que vous essayez d'accomplir, cela demande de la concentration et de la puissance. (Tout change constamment, tu n'as jamais fini)
Restez fidèle à une ou deux technologies et vous endurerez. (COBOL paie toujours bien, tout comme C)
Quitter la programmation et passer à la gestion, c'est être éternellement présent. (ou laissez un héritage de logiciels FOSS que tout le monde continuera à utiliser bien après votre mort).
La question, en un mot, est de savoir si ces choses deviennent plus claires pour un programmeur alors 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 au fur et à mesure que vous en apprenez plus, ou est-ce que cela devient plus compliqué au fur et à mesure? Comment pouvez-vous combattre ce sentiment que vous êtes 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, et je vais le démontrer avec une analogie simple.
Pensez à quand vous avez commencé à faire du sport. Au tout début du premier sport que vous avez appris, la coordination de base pour les tâches simples d'un seul sport semblait probablement très difficile. Comme vous avez acquis un peu plus d'expérience, vous avez commencé à maîtriser les tâches simples afin de ne plus avoir à y penser, et vous avez remarqué qu'il y avait des tâches plus complexes auxquelles vous pouviez prêter 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 de celui de baseball, mais quelqu'un qui maîtrise l'un d'entre eux aura beaucoup plus de facilité à prendre l'autre qu'une personne qui n'a jamais fait l'un ou l'autre auparavant. Grâce à votre expérience de la pratique d'un deuxième sport, vous avez découvert que le premier sport vous donnait à la fois des compétences spécifiques et génériques. Des compétences spécifiques (attraper un ballon de basket) ne sont utiles que dans leur domaine, mais des compétences génériques (suivre un objet en mouvement rapide s'approchant 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 ce langage) en tant que compétences spécifiques, mais vous avez également acquis de précieuses compétences génériques: comprendre comment les ordinateurs fonctionnent en interne et comment exprimer vos intentions d'une manière qu'un ordinateur peut 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 tirés à travers tous les langages informatiques comme les dépôts minéraux posés le long d'une paroi de canyon. Une fois que vous vous êtes vraiment familiarisé avec quelques langages différents, vous commencez à être capable de reconnaître la "forme" de la plupart des codes, si vous pardonnez le flou, même si vous ne savez rien de 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 de petites parties d'un algorithme séparément et de les composer dans une solution complète plus tard
- 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 peut-être chargement de bibliothèques communes)
- Les déclarations antérieures ont priorité et affectent les déclarations ultérieures, c'est-à-dire que l'ordinateur démarre en haut du code et descend
Plus vous faites de programmation, plus vous vous rendrez compte que peu importe la forme de la balle, c'est toujours une balle qui vient vers vous, et vous savez quoi en faire sans avoir à trop y penser. Toute programmation consiste à tenter d'exprimer vos intentions d'une manière que l'ordinateur peut comprendre; apprenez suffisamment et vous pourrez commencer à lire les intentions au lieu du code.
P.S.- Chaque fois, lorsque vous commencez enfin à vous sentir comme si vous connaissiez votre chemin, vous rencontrerez quelque chose qui vous casse 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.
C'est une source sans fin d'étonnement (et d'anxiété) sur le nombre de langages informatiques et la mesure dans laquelle ils changent constamment. 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'IDE.
Toutes ces variations ont deux dimensions de complexité.
- Leur vocabulaire et leur syntaxe sont différents.
- Les abstractions (concepts de haut niveau) qu'elles prennent en charge sont différentes.
Ils ont également une chose en commun. Turing complétude. Avec suffisamment d'efforts 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 C (petit vocabulaire, syntaxe complexe et presque aucune abstraction), vous avez définitivement l'impression de pouvoir tout faire (à juste titre).
Ensuite, passez à des "trucs faciles" comme CSS, HTML, Javascript et peut-être aussi des frameworks comme Bootstrap et React, et votre cerveau va frire - comme le ferait Albert Einstein. Les gens pensent "Je connais le français, donc apprendre l'allemand devrait être facile ". Non!
De nombreuses abstractions de programmation peuvent être tirées de modèles de logiciels. Il existe plusieurs livres dédiés au sujet. Les modèles sont partout, sont indépendants du langage et peuvent être appris et compris ne fois. Si vous connaissez vos modèles, vous pouvez les utiliser dans n'importe quelle langue et les reconnaître lorsqu'ils sont intégrés dans des langues et plus fréquemment dans divers cadres.
Il faut à la plupart des gens un à deux ans pour parler couramment une nouvelle langue et les employeurs le savent. C'est pourquoi ils n'embauchent pas de personnes qui ne connaissent pas 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 de l'informatique, les modèles de logiciels et le type de problèmes commerciaux que vous rencontrez, tout cela change lentement. Vous pouvez apprendre une fois et accumuler progressivement de nouvelles connaissances. A l'inverse, les langages informatiques, les frameworks, dits "écosystèmes" et les bibliothèques de composants évoluent très rapidement comme le font tous les outils qui les entourent. Ici, attendez-vous à un rythme d'apprentissage lent et long!
Réponse courte: Oui, en général
Cependant, vous ne deviendrez pas un spécialiste si vous généralisez. Devenir spécialiste, c'est aussi réaliser toutes les choses que vous ne savez pas: cela peut être un sentiment écrasant.
Au fil du temps, vous gagnez de l'expérience.
Au fil du temps, d'autres langages/modèles, etc. se développent parallèlement à votre développement.
Une autre variable de votre question est de savoir si vous acquérez une expérience significative par rapport à l'industrie car elle évolue également dans le même temps constant. L'industrie technologique est une cible mouvante et contrairement à la plupart des autres industries.
Une bonne question pourrait également être, si vous vous étalez trop mince ou trop épais sur une certaine langue.