La recherche constante d'exemples de code est-elle le signe d'un mauvais développeur?
Je suis un étudiant CS avec plusieurs années d'expérience en C et C++, et depuis quelques années je travaille constamment avec Java/Objective C pour le développement d'applications et maintenant je suis passé au développement web et je me concentre principalement sur Ruby on Rails et je me suis rendu compte que (comme pour le développement d'applications, vraiment) je fais trop référence à d'autres codes. J'utilise constamment la fonctionnalité Google pour beaucoup de choses que j'imagine que je devrais être capable de faire à partir de zéro et cela a vraiment un peu ébranlé ma confiance.
Les principes de base ne sont pas un problème, je déteste utiliser ceci comme exemple mais je peux parcourir javabat en Java/python à un sprint - évidemment pas un accomplissement et mais ce que je veux dire, c'est que j'ai une base solide pour les principes de base Je pense?
Je sais ce que je dois utiliser généralement, mais je fais constamment référence à la syntaxe. J'adorerais avoir des conseils et des commentaires à ce sujet, car cela me retient assez fermement en termes de recherche d'emploi dans ce domaine, même si je termine mon diplôme. Ma principale raison de demander n'est pas vraiment au sujet de l'emploi, mais plus que je ne veux pas être le seul gars à un hackathon à ne pas marteler le code sans escale et assis là avec 20 onglets Google/github ouverts, et je me suis abstenu d'assister à tout en raison d'un léger manque de confiance ...
Une personne est-elle un mauvais développeur en cherchant constamment des exemples de code pour des tâches modérées à complexes?
Copiez-collez aveuglément: mauvais.
Recherchez de la documentation, lisez des exemples de code pour mieux comprendre: bon.
Je préfère travailler avec quelqu'un qui regarde les choses tout le temps et s'assure que tout fonctionne comme prévu plutôt que quelqu'un trop confiant qui pense qu'il sait tout mais pas. Mais le pire, c'est quelqu'un qui ne prend pas la peine de comprendre comment les choses fonctionnent, et qui copie simplement le code à partir du Web sans critique (et puis lorsque les rapports de bogues commencent à pleuvoir, il ne peut rien réparer correctement).
Si vous codez vos solutions de manière maintenable et COMPRENEZ réellement ce que vous copiez/collez/modifiez, il n'y a pas de problème.
Je meurs à l'intérieur chaque fois que je pose des questions à un développeur senior sur la raison pour laquelle il a fait quoi et la réponse est "Je ne sais pas, j'ai copié collé le code et cela a fonctionné à ce moment-là".
Tout comme avec la compétence pour programme avec/sans documentation API , à la recherche d'exemples de code est un signe non pas d'un mauvais programmeur, mais de celui qui manque maîtrise ...
... Ici, je parle de maîtrise. A propos d'être non seulement capable de quelque chose mais fluide.
Savez-vous ce que c'est que de parler couramment? C'est quand, pour quelqu'un qui vous regarde, il semble que vous codiez en tapant ...
- ... Comme si le bon code coule simplement de vos doigts vers l'écran. Comme si vous ne consultez pas les documents, les didacticiels et les manuels de l'API. En fait, vous faites vérifiez-les tous, mais c'est invisible parce que tout est dans votre tête. Vous avez toutes les connaissances dont vous avez besoin dans votre cerveau - chargées, chargées et prêtes à l'emploi.
... C'est une connaissance courante. C'est quand il vous faut une minute pour faire ce qui prend une heure au débutant. Ça vaut vraiment la peine. Ça sent la victoire.
... et la pratique est pour moi le seul moyen fiable d'acquérir la maîtrise.
Il y a une théorie de l'apprentissage appelée cycle de Kolb (d'après la personne qui l'a décrite). Les entrées de ce cycle sont:
Concrete experience -> Reflective observation
^ |
| v
Active experimentation <- Abstract conceptualisation
Différentes personnes aiment commencer à différents endroits du cycle. Il est donc tout à fait possible d'apprendre en en recherchant des échantillons (la phase d'observation réfléchie), puis en travaillant à partir de ces échantillons vers la grande image via l'abstraction.
D'autres personnes apprendront de différentes manières: certaines personnes aiment commencer par essayer (c'est-à-dire par l'expérimentation), puis réfléchir à ce qui s'est bien passé ou pas. Le fait est que ce ne sont que des façons différentes d'attaquer le problème de l'apprentissage des choses: aucune d'entre elles n'est incorrecte.
Divulgation complète - Je suis une personne âgée qui a été formée dans un autre pré-Internet disponible à l'ère du travail. J'ai vu les compétences des jeunes développeurs se détériorer régulièrement, principalement parce qu'ils ne conservaient pas les informations ou ne comprenaient pas la solution qu'ils avaient récupérée sur Internet. J'ai observé que le niveau de compétence qu'une personne avait après 1-2 ans d'expérience, il y a 20 ans, est maintenant le niveau de compétence que quelqu'un a après 5-7 ans d'expérience. (Oui, c'est une observation personnelle mais j'ai fait beaucoup d'embauches, je n'ai pas de données statistiques sur le sujet et oui, je suis parfois vieux et grincheux, prenez cette déclaration avec un grain de sel. Et restez hors de ma cour. )
Rechercher tout est inefficace en termes de temps. C'est aussi un symptôme de quelqu'un qui n'a pas beaucoup de connaissances approfondies. Les personnes possédant des connaissances approfondies peuvent écrire du code plus rapidement que les personnes qui ne savent pas comment résoudre un problème sans rechercher les choses. Il vaut donc la peine d'apprendre à gérer plus de choses sans avoir à chercher continuellement.
Maintenant, je ne dis pas que vous ne devriez jamais chercher les choses, je dis que vous devez apprendre à conserver les connaissances et à ne chercher que les choses que vous utilisez rarement ou lorsque vous rencontrez un problème, un langage ou un paradigme véritablement nouveau. Et je ne dis pas que vous ne devriez pas lire pour suivre les nouvelles solutions, les nouveaux outils et les nouveaux langages.
Ma vraie préoccupation pour les développeurs qui recherchent trop souvent des choses, c'est que trop d'entre eux (pas nécessairement vous) ne développent jamais les compétences analytiques pour comprendre les problèmes qu'ils ont et les solutions qui sont nécessaires. Lisez le nombre de questions où la personne met dans le message d'erreur qu'elle ne comprend clairement pas, mais qui devraient être assez claires pour toute personne opérant au niveau professionnel. Ou ceux où la personne dit: "ça ne marche pas, pourquoi?" sans référence au message d'erreur ou à la façon dont il ne fonctionne pas et le code est syntaxiquement correct. Ou ceux à qui on a donné un morceau de code qui devrait fonctionner, mais dans la hâte de répondre d'abord, la personne a fait une erreur de syntaxe évidente (comme dire manquer le mot-clé ON dans une jointure SQL pour utiliser un exemple que j'ai vu aujourd'hui) et l'affiche revient avec une erreur à la ligne 12. Pourquoi oui, si vous regardez à la ligne 12, il est évident quelle est l'erreur si vous avez des compétences de base.
Donc, si ce que vous recherchez est un élément qui fait partie des fonctionnalités de base du ou des langages (BTW, cela devrait inclure SQL si vous accédez à des bases de données) que vous utilisez depuis plus de six mois, je soupçonne que vous recherchez également beaucoup. Si ce que vous recherchez sont des fonctionnalités avancées, en particulier celles que vous pourriez utiliser rarement, alors tout va bien.
Mais comment apprendre à conserver plus d'informations? Comprenez d'abord pourquoi le code s'est cassé. Même si quelqu'un vous donne une solution de travail, si vous ne voyez pas pourquoi cela a fonctionné et que la vôtre n'a pas fonctionné, alors demandez. Si vous ne comprenez pas le message d'erreur, demandez-lui ce qu'il signifiait, puis essayez de le résoudre vous-même.
Et ne coupez et collez jamais une solution que vous ne comprenez pas. En fait, ne coupez et collez pas du tout. Si vous souhaitez conserver des informations, vous devez les saisir. En fait, l'écriture physique du code vous-même vous aide à l'apprendre. C'est une technique d'apprentissage bien connue.
Entraînez-vous à généraliser votre compréhension du code. J'ai vu des gens poser des questions similaires à maintes reprises au fil du temps parce qu'ils ne comprennent pas que la solution qu'ils ont obtenue il y a un mois au problème ABC est la même solution au nouveau problème DEF.
Donc, lorsque vous avez fait des recherches, prenez le temps de réfléchir aux types de problèmes qu'il serait bon de résoudre et écrivez-vous des notes à ce sujet. Ensuite, lorsque vous avez un problème à résoudre, vérifiez d'abord vos propres notes pour voir si vous avez déjà noté une technique possible. Si vous évaluez plusieurs façons de résoudre un problème, prenez des notes sur le type de problème, les solutions possibles que vous avez examinées et les avantages et les inconvénients de chacun. Encore une fois, la prise de notes aide à solidifier les connaissances dans votre cerveau, vous avez déjà votre propre processus de réflexion en termes d'avantages et d'inconvénients et vous n'avez pas à le faire à nouveau (ou du moins pas aussi en profondeur, vous pouvez chercher encore plus de techniques possibles) pour le prochain problème similaire.
Et pour décider quoi apprendre ensuite, approfondissez l'une de vos principales technologies avant de vous lancer dans l'apprentissage des 30 premiers jours d'une autre technologie (cela suppose que vous avez suffisamment de connaissances pour effectuer votre travail, si vous en avez besoin). utilisez 6 technologies - obtenez les bases dans les six avant d'aller en profondeur). Ensuite, allez-y, apprenez de nouvelles choses, à un niveau de base, apprenez quelque chose de plus en profondeur, puis apprenez plus de nouvelles technologies à un niveau de base. Si vous le faites au fil du temps, vous constaterez que votre niveau de base de ce que vous voulez d'une nouvelle technologie est beaucoup plus profond parce que vous comprenez des questions plus avancées à poser à ce sujet.
Une autre façon d'apprendre à conserver les connaissances est de les enseigner à quelqu'un d'autre. Répondez à des questions dans des endroits comme celui-ci, présentez des sujets de formation à votre équipe, faites des présentations à vos groupes d'utilisateurs locaux, rédigez des entrées de blog et aidez à maintenir un wiki d'informations dans votre entreprise pour aider d'autres développeurs.
La recherche d'exemples de code n'est pas un signe de mauvais développeur. On a rarement besoin de si peu de choses pour se souvenir de toutes les interfaces dont elles ont besoin avec précision, il est donc naturel de rechercher les choses et les exemples de code sont généralement la référence la plus facile à utiliser.
Ce que vous ne devriez pas faire, c'est copier-coller des exemples, car ils fonctionnent là-bas, ils doivent donc travailler ici aussi, sans comprendre comment ils fonctionnent. Cela conduit généralement à beaucoup de bits inutiles qui ont été copiés accidentellement, le résultat étant difficile à maintenir car si vous ne saviez pas comment cela fonctionne lorsque vous l'avez écrit, vous ne le saurez pas non plus six mois plus tard et vous ne pourrez pas répare le.
Mais tant que vous comprenez le code que vous copiez à partir d'un exemple, c'est un moyen valide pour faire le travail plus rapidement, et c'est généralement une bonne chose.
Ces réponses sont plutôt bonnes. Mais vous souffrez d'un problème beaucoup plus profond que le copier/coller ou le manque de "compétence".
La comparaison est mortelle. Plus vous vous comparez à d'autres personnes et laissez leur talent affecter la façon dont vous vous voyez, plus vous vous rétrécirez et mourrez à l'intérieur. Vous n'allez pas aux hackathons à cause de peur que les gens verront à quel point vous êtes sans talent. Et la seule raison pour laquelle vous pensez que vous êtes sans talent, c'est parce que vous vous comparez à des pirates qui peuvent frapper plus de code à partir de zéro, plus rapidement.
Même si "Lignes de code par minute" était une bonne mesure pour mesurer les compétences, vous devez accepter le fait que il y aura toujours de meilleurs développeurs que vous. Et c'est ok pour montrer aux autres que vous manquez de compétences.
Vous n'avez pas besoin d'être aussi bon ou meilleur que quiconque. Vous devez vous contenter du fait que vous manquerez toujours d'une manière ou d'une autre et que vous apprenez constamment. Si vous ne pouvez pas être satisfait d'être un développeur inférieur, vous ne serez JAMAIS heureux.
Une dernière chose: votre peur du rejet par des gens que vous pensez être "supérieurs" est exactement ce qui vous empêche de côtoyer de meilleurs développeurs et d'apprendre d'eux. Votre peur vous empêche donc de grandir, ce qui maintient votre peur. Ce qui vous empêche de grandir. Voir le cycle? Vous devez briser le cycle quelque part.
Je pense que cela dépend en grande partie du fonctionnement de votre esprit. Ma mémoire pue, donc je préfère de loin récupérer du code aussi proche de ce que je veux que possible et le retravailler pour qu'il fasse le nouveau travail. Il sert d'exemple et de rappel de tout ce que je dois faire. Par exemple, j'utilise du SQL simple depuis 20 ans, mais je ne me souviens jamais de la disposition d'une instruction SELECT ou UPDATE. (Je pense que l'on a besoin de parenthèses, mais je ne me souviens pas laquelle.) D'un autre côté, quelques pe choses dont je me souviens; Je peux lancer ensemble un Java Implémentation de l'itérateur les yeux fermés.
La plupart du code que je copie est le mien, mais j'en copie certainement d'autres lorsque j'apprends quelque chose de nouveau.
Je ne connais pas les hackathons. Ils peuvent puiser dans un sous-ensemble de programmeurs possédant des souvenirs photographiques. Je vais essayer et voir. Si ressembler à un idiot vous dérange, vous ne devriez pas programmer.
Je vous exhorte à bien comprendre tout le code que vous copiez et modifiez, mais jusqu'à ce que je lise certaines des autres réponses, il ne m'est jamais venu à l'esprit que quelqu'un pourrait copier sans comprendre. (Il me semble que j'apprends tout le temps de nouveaux vices sur ce site ...)
... Je me suis rendu compte que ... je fais trop référence à d'autres codes. J'utilise constamment la fonctionnalité Google pour beaucoup de choses que j'imagine que je devrais être capable de faire à partir de zéro et cela m'a vraiment un peu ébranlé la confiance.
Alors arrête. Dirigez-vous dans l'autre sens pendant un moment. Implémentez tout vous-même, même si vous savez vous pourriez trouver exactement la chose dont vous avez besoin en beaucoup moins de temps.
Ce qui s'est passé, c'est que votre muscle de résolution de problèmes (nom latin gluteus mojo) s'est atrophié de la désuétude, et vous évitez maintenant de l'utiliser parce que vous savez à quel point il est faible. Vous devez commencer à construire et à tonifier ce muscle tout comme vous travaillez sur vos biceps au gymnase. Commencez avec des répétitions élevées et une faible résistance - beaucoup de problèmes faciles. Au fur et à mesure que vous gagnez en confiance, passez à des problèmes plus longs et plus difficiles.
Vous sentirez progressivement votre mojo revenir et votre besoin de compter sur Google diminuera. Continuez à exercer ce muscle, cependant, et assurez-vous de ne pas retomber dans vos anciennes habitudes. Relevez le défi de résoudre un problème d'abord et seulement ensuite recherchez d'autres solutions. Parfois, vous constaterez que d'autres ont trouvé une meilleure façon de faire la même chose, d'autres fois, vous déciderez que votre propre solution est meilleure.
Une personne est-elle un mauvais développeur en cherchant constamment des exemples de code pour des tâches modérées à complexes?
Une personne qui est incapable pour faire quoi que ce soit sans trouver d'exemples est un mauvais développeur. Le fait est que vous ne saurez pas si vous en êtes capable ou non avant d'avoir essayé.
Vous êtes jeune et vous avez travaillé avec de nombreux langages de programmation. Je vais deviner que vous apprenez probablement les nouvelles langues plus rapidement que les anciennes. Vous n'avez toujours pas mis suffisamment de temps dans une seule langue sur une application suffisamment grande pour développer la fluidité.
Êtes-vous à la recherche de solutions générales à chaque fois comme: l'ensemble du processus de connexion d'une grille Web à une table de base de données ou une partie plus petite comme le formatage de la chaîne de connexions (je dois rechercher cela à peu près à chaque fois depuis que j'écris environ quatre par an. )?
Vous serez toujours à la recherche de références à la syntaxe de différentes lignes de code ou de fonctions. Plus vous programmez, plus vous rencontrez de défis et d'environnements et de changements de langue différents. Si vous avez besoin d'un tutoriel complet à chaque fois que vous faites quelque chose, alors vous avez un problème.
J'avais un professeur qui disait qu'il détestait faire des tests en essayant de conserver un tas d'informations que vous aviez entassées la nuit précédente parce que vous en oubliez beaucoup par la suite de toute façon. Il vaut mieux connaître vos ressources et que vous pouvez les utiliser correctement pour trouver les informations que vous ne connaissez pas. J'aime appliquer un principe similaire à tout ce que je fais, y compris le travail.
Je pense que les outils les plus importants dont vous disposez sont vos ressources, tant que vous les utilisez correctement. Ainsi, lorsque j'écris du code, je vais le plus loin possible avec mes connaissances existantes, puis je fais des recherches en demandant à d'autres programmeurs ou en cherchant sur Internet, afin de mieux comprendre la solution appropriée. Les connaissances se développeront au fil du temps et après un certain temps, vous connaîtrez et comprendrez mieux les compétences naturellement. Je recherche constamment des informations, que j'aie réellement besoin des informations ou non, et je peux honnêtement dire que j'apprends quelque chose de nouveau chaque jour.
Si vous comprenez le problème que vous essayez de résoudre et comprenez comment vous voulez le résoudre, rechercher la syntaxe correcte n'est pas un gros problème à mon avis.
J'ai obtenu mon diplôme il y a environ deux ans et j'ai été jetée aux loups lorsque j'ai obtenu mon emploi. J'ai dû apprendre, maintenir et mettre à niveau une grande application écrite dans une langue que je n'avais jamais touchée auparavant. Je recevais un rapport de bogue, parcourais le code et découvrais comment je voulais le corriger, puis je devais trouver sur Google des exemples de la façon de faire ce que je voulais dans cette langue.
Si vous faites avancer les choses et que vous les comprenez suffisamment pour ne pas produire de désabonnement inutile, alors vous êtes probablement d'accord.
Je pense que lire des exemples de code, et simplement lire le code source de ce que les autres ont développé en général, est la meilleure façon d'améliorer vos compétences. Je pense vraiment que cela ouvre des portes dans votre cerveau qui n'auraient pas été ouvertes autrement.
Si vous pensez à une solution A et que quelqu'un d'autre pense à une solution B, lorsque chacun de vous partage vos solutions, vous pouvez réaliser la solution C qui peut être encore meilleure que A ou B.
Le développement de logiciels dans un environnement d'entreprise nécessite une bonne quantité de réutilisation de code. Pourquoi réécrire une fonction/méthode si un API existe déjà et est largement utilisé? Il sera très probablement aussi efficace que tout ce que vous écrivez et prendra moins de temps.
Bien sûr, réussir le développement de logiciels nécessite également une pause du clavier, afin que vous puissiez lire et comprendre ce qui se passe réellement. Prenez n'importe quel cadre Web. Vous devez savoir ce qui se passe en dessous afin de comprendre le code que vous écrivez, mais vous n'aurez probablement jamais à écrire vous-même un framework Web à partir de zéro.
Il vous suffit d'écrire du code qui tire parti du type de framework (disons qu'un framework basé sur des composants nécessite un certain style) et cela vient de la compréhension de l'image plus grande. Apprenez l'image plus grande et tout ira bien.
Je pense qu'il existe de nombreux niveaux de compétence en développement logiciel. Tout simplement parce qu'il existe également de nombreux niveaux de compétence en développement de documentation . Franchement, de nos jours, les systèmes sont des ordres de grandeur plus complexes que lorsque j'ai commencé à programmer des ordinateurs au milieu des années 80.
Ensuite, vous deviez savoir ce que vous vouliez que l'ordinateur fasse, et vous aviez une documentation écrite de 6 pouces d'épaisseur vous expliquant comment l'ordinateur faisait certaines choses plus élémentaires. Mettre ce que vous vouliez dans une forme que l'ordinateur pourrait prendre était une question de connaître le contenu des index de ces livres et un langage de programmation (ou deux. Vraiment, après avoir appris quatre ou cinq langues, les autres ne sont que des dialectes.)
Aujourd'hui, cette tâche nécessite de connaître un langage, de connaître un système, de connaître un paradigme, un modèle de programmation et au moins un ensemble d'API, qui sont tous des cibles mobiles.
Donc, une personne avec un certain niveau de connaissances de base qui pose des questions n'est pas un bon type de programmeur. Il est le meilleur type de programmeur, étant donné les environnements d'aujourd'hui et le désintérêt des entreprises comme Microsoft pour appliquer toute sorte de rigueur à leur propre documentation sur les fondamentaux. La plupart de leurs contenus sont des documents de référence autoréférentiels et certains très mauvais exemples de code. (Deux cas concrets que j'ai rencontrés sont "Windows Installer" et les API pour créer des fichiers vidéo WMV.)
Parce que Microsoft, Google et, dans une moindre mesure, Apple, comptent tous sur "la communauté" pour compenser cette carence très réelle, demander n'est pas seulement important, c'est vital. Et être une personne à qui l'on peut demander et qui peut donner des réponses et des commentaires solides dans l'environnement d'aujourd'hui est tout aussi vital. C'est pourquoi des sites tels que les sites stackexchange.com sont aussi utiles qu'ils le sont.
Alors posez des questions, (demandez intelligemment!) Des échantillons, et respectez les personnes qui fournissent les réponses, et ce faisant ne sera pas considéré comme un signe de un "mauvais développeur".
Et encore une chose: fournir de mauvais échantillons est vraiment le signe d'un mauvais développeur. Cela rend les mauvais développeurs plus faciles à repérer, mais gomme également les recherches Google. Si vous manquez de confiance dans des échantillons de code simples, directs et spécifiques, ne les donnez pas.
Et, s'il vous plaît, ne vous moquez pas de ceux qui demandent.
Il me semble que le problème pour vous est moins de comprendre ce à quoi vous faites référence, et plus de problèmes de facilité et de mémoire. Si cela mine votre confiance, alors oui, c'est un problème - mais il peut certainement être résolu!
Pour moi, ce genre de défis se présente dans de nombreux aspects de ma vie. Par exemple, pour réussir à jouer un morceau de musique, j'ai besoin de développer mon indépendance par rapport aux partitions qui me sont données - comment ressentez-vous vraiment la musique si votre nez est toujours enfoui dans votre livret? Parfois, si j'ai le temps, je mémorise l'ensemble de la musique - même si ce n'est pas nécessaire pour mon concert. Pourquoi? Avec la partition disparue, il est beaucoup plus facile pour moi de me concentrer sur les aspects les plus difficiles et les plus généraux de la musique dont j'ai besoin pour bien faire, et il est beaucoup plus facile pour moi d'entrer dans cette zone incroyable de création musicale pure. Je trouve donc que cela vaut bien la peine supplémentaire.
Mon expérience avec la programmation a été similaire. Je pense que les clés sont:
- pratiquer la langue - la taper, l'exécuter, la parler si cela aide; faites-le à plusieurs reprises.
- construisez votre installation - utilisez la même fonction ou le même modèle dans différentes situations; rassembler les fonctionnalités; faire des programmes.
- donnez suffisamment de temps entre les répétitions pour vous assurer que les choses font vraiment leur chemin dans votre mémoire à long terme.
Ces principes semblent s'appliquer lors de l'apprentissage d'une langue, en fait! Voir Comment se souvenir de nouveaux mots par exemple. La méthode Pimsleur fonctionne aussi comme ça.
J'ai trouvé que presque tous les principes, la syntaxe et les bibliothèques communes du langage et des technologies que j'utilise régulièrement peuvent être complètement mémorisés en utilisant ces touches. Même ainsi, je fouille constamment Internet pour trouver des exemples et de la sagesse! Mais à ce stade, je recherche une validation sur le problème que j'essaie de résoudre, les différentes approches qui ont été adoptées, les outils qui peuvent aider et la consultation pour les bibliothèques moins fréquemment utilisées. C'est un type de recherche très différent de celui que j'utilise lorsque j'apprends une langue et au fond des tutoriels et des manuels.
De votre histoire, voici quelques obstacles spécifiques que je pense que vous pourriez rencontrer.
- Si vous rencontrez des difficultés avec la syntaxe, vous n'aurez peut-être pas assez de pratique. Cela est particulièrement vrai si vous copiez et collez directement dans votre code, au lieu de développer la répétition et - puis-je dire? - mémoire musculaire qui vous aidera à devenir vraiment bon. Pour contrer cela, développez simplement des exercices et de la discipline, en vous concentrant sur la répétition et le temps, qui amélioreront votre installation dans les domaines que vous souhaitez. Suggestions:
- Écrivez un programme simple dans la même langue une fois par jour, tous les jours.
- Tapez des exemples au lieu de les copier-coller.
- Si vous avez du mal à trouver des solutions à des problèmes de taille moyenne, vous n'aurez peut-être pas suffisamment d'expérience dans la construction. Essayez-les:
- Démarrez un projet de taille moyenne dans une technologie ou une langue dans laquelle vous souhaitez vous perfectionner. Ou essayez-vous à une fonctionnalité plus volumineuse sur un projet open-source qui vous intéresse. Détaillez-le un peu tous les jours. (N'oubliez pas, lorsque vous poursuivez ces grands projets: allez-y brique par brique. N'essayez pas de construire le tout en même temps!)
- Utilisez la même nouvelle fonctionnalité pendant quatre jours consécutifs, dans quatre contextes différents.
- Relevez le défi de coder quelque chose avec le navigateur Web désactivé!
- Prenez des notes sur les choses que vous apprenez. Synthétisez ce que vous apprenez et notez vos observations. (En fait, écrire des choses et me forcer à exprimer quelque chose dans mes propres mots m'aide beaucoup.)
- Écrivez les réponses et vérifiez-les pour les questions StackOverflow sur la technologie que vous absorbez. (Cela a souvent l'avantage supplémentaire de vous faire gagner une petite réputation pendant que vous apprenez. :-))
- Vous étalez peut-être votre pratique trop finement. Vous semblez travailler dans de nombreuses langues différentes. Cela a beaucoup d'avantages, mais cela a l'inconvénient de diluer votre expérience. Si vous passez du temps à travailler dans cinq langues différentes, vous mémoriserez moins que si vous passiez le même temps dans une langue. Pire encore, il y a beaucoup de parents pas tout à fait similaires entre les différentes langues (était-ce autre si, elsif ou elif ??) pour vous trébucher. Pour contrer cela, affinez votre concentration. Choisissez une chose à apprendre et apprenez-la à froid. Passez ensuite à la chose suivante.
Je pense que si vous vous concentrez sur l'élaboration de code modéré vous-même, votre efficacité et votre productivité augmenteront. Il faut probablement plus de temps pour rechercher du code, le lire/le comprendre, le copier votre source, le modifier en conséquence, etc.
Si vous le proposez vous-même, il est probablement plus adapté à votre situation spécifique, et après un certain temps, ces solutions vous arriveront plus rapidement que de les rechercher.
La façon dont je vois les choses, c'est que c'est comme si vous vouliez un deuxième avis sur une certaine solution, alors vous regardez comment les autres (sur Internet) le font. Si vous vous surprenez à trop faire ou à vouloir cela, pensez à demander à un collègue ce qu'il pense d'une solution. Si vous posez une question à votre collègue toutes les 15 minutes, il/elle sera probablement agacé. Par conséquent, vous poserez moins de questions et essaierez de le faire vous-même.
Visualisez cela lorsque vous souhaitez rechercher des informations sur Internet.
Le copier-coller pur et non critique, comme indiqué à plusieurs reprises dans ces réponses, est mauvais. Mais il en va de même pour tout. S'il ne s'agit pas d'un composant essentiel au cœur de votre entreprise, recherchez une bibliothèque ou un extrait de code pour le faire en premier. L'exception à la recherche d'un extrait serait que le problème est très simple, vous avez une image très claire sur la façon de le faire et si vous n'utilisez pas de bibliothèque: que vous n'aurez probablement pas besoin de faire plus.
Je sais personnellement que si j'écris quelque chose de courant, je risque d'avoir des bogues subtils et peut-être un ou deux bogues moins subtils sans beaucoup de tests. Je recherche donc une solution similaire, la modifie et la teste pour gagner du temps sur les tests et le développement sur l'ensemble. Parce qu'en fin de compte, je suis responsable de la livraison d'un produit qui fonctionne, qui est extensible, qui respecte le budget ou le respecte et qui respecte les délais. La réutilisation du code et des bibliothèques est un bon pas vers cet objectif.
La meilleure façon d'apprendre ce que vous ne savez pas: google it! Je pense que vous avez raison au même niveau que la plupart des développeurs. Mettez le complexe d'infériorité dans votre sac à dos et entrez avec l'esprit ouvert.
N'ayez pas peur de poser des questions, de faire des recherches sur Google, d'essayer et d'échouer. Tout cela en fait partie.
Il ressort clairement des réponses déjà données qu'il n'y a rien de mal à rechercher votre problème, au lieu de coder aveuglément. Mais la question qui n'a pas été abordée, parce que vous ne l'avez pas posée directement, est pourquoi vous sentez-vous si peu sûr - et que pouvez-vous faire à ce sujet? Après tout, beaucoup de gens recherchent les problèmes sur Google et ont confiance en eux (même ceux qui ne devraient pas ...)
Alors que faire? Peut-être que vous aviez juste besoin de quelques centaines de tapotements au dos, que vous venez de recevoir, et que vous pouvez maintenant coder en toute confiance. Mais si cela n'a pas fonctionné, je vous suggère de vous pencher sur les tests automatisés et le développement piloté par les tests. Rien ne dit "bien fait" comme un "Tous les tests réussis" de votre suite de tests: Lorsque vous y arrivez, vous savez vous l'avez fait correctement.
Vous devriez également essayer de vous mettre un peu au défi: vous dites que vous recherchez toujours la syntaxe que vous connaissez déjà; alors forcez-vous à écrire du code sans chercher la syntaxe, et vous découvrirez (bientôt, sinon immédiatement) que vous vous débrouillez bien après tout.
Les développeurs ne naissent pas "grands", mais la grandeur ne vient pas automatiquement avec l'expérience. Inversement, le manque d'expérience ne rend pas un développeur "mauvais". La différence entre un grand développeur et un mauvais développeur n'est pas dans leur connaissance du domaine, mais dans leur méthodologie. La marque distinctive d'un grand développeur est qu'il code consciemment. Autrement dit, un bon développeur sait toujours pourquoi il fait quelque chose. Du point de vue de l'éthique personnelle, cela requiert du courage intellectuel et de l'intégrité.
Il est si important de prendre un peu de temps et de comprendre les bases, des choses plus complexes s'appuyant à peu près sur cela. S'il n'y a aucun fondement dans la compréhension de la langue et de ce qui se passe dans les coulisses, le codage sera simplement du piratage…
Je vois donc que vous avez mentionné que vous alliez à un hackathon. Je suis allé à pas mal l'année dernière (plus de 15) et j'ai remarqué qu'ils sont parfaits pour apprendre. Et par grand pour l'apprentissage, je veux dire apprendre à ne plus jamais coder comme ça. J'essaie surtout de faire quelque chose de nouveau à chaque hackathon auquel je vais juste pour apprendre de nouvelles choses. Comme il y a une énorme contrainte de temps, vous devez simplement copier-coller tout le code que vous pouvez trouver et cela vient vous mordre dans le cul lorsque vous le testez.
Cependant, de bonnes choses en ressortent, vous: A) APPRENEZ tellement pendant les tests de bogues (pleurez aussi fortement) B) Sachez de ne plus jamais coder comme ça et apprenez de meilleures pratiques de codage. De plus, lors des hackathons, vous rencontrerez des gens qui peuvent vous enseigner tant de nouvelles choses que vous ignoriez et vous ferez des choses que vous n'allez jamais faire à l'école.
Donc, ce que je dis, c'est que le copier-coller est mauvais, et vous n'apprendrez rien, et le temps que vous avez économisé par le copier-coller vous mordra plus tard pendant les tests de bogues et vous n'avez aucune idée de ce que vous avez même écrit, il est 8 heures du matin, et sont alimentés avec toute la caféine. Mais, je pense que tant que vous testez votre code, vous DEVEZ apprendre tout ce que vous avez copié auparavant.
Donc, lire des livres avec des exemples et s'y référer est une mauvaise programmation, c'est le contexte de votre question. Eh bien, vu que peu de gens documentent leur API, un livre est tout ce qu'il nous reste.
Je ne sais pas quelles sont vos raisons pour poser cette question, vous pouvez peut-être y répondre vous-même après avoir lu ma situation car je me réfère à de nombreux exemples de code.
Je n'ai jamais eu la chance d'aller à l'université car j'étais dans la rue à l'âge de 16 ans. À 24 ans, j'étais en mesure d'étudier dans un collège par correspondance et de faire des certifications de vendeur comme SCJP, SCJD, SCBCD et SCWCD. Je dois admettre que parfois j'ai eu du mal et j'ai dû me tourner en ligne pour des exemples. Sans le savoir, à cette époque, j'avais une tumeur au cerveau qui poussait dans ma tête (en 2010, elle avait la taille d'une orange). Après mes 5 chirurgies cérébrales, 6 semaines combinant chimio/radiothérapie et 10 mois de chimio, je suis toujours en train de programmer avec des sites codés à la main qui sont visibles depuis mon profil.
Oui, j'ai besoin de beaucoup d'exemples de code avec des lésions cérébrales, cela fait-il de moi un mauvais programmeur?
Eh bien, je ne m'appelle pas un bon programmeur. Mais ce que je fais est simple. Si je ne sais pas comment faire quelque chose, je regarde un code/exemple sur Internet. Ensuite, après l'avoir lu, j'essaie de le réécrire, de l'optimiser et d'utiliser le truc qui convient le mieux au code que je veux.
Remarque: La lecture de code sur Internet ne fait pas faire de vous un mauvais développeur. Il est toujours bon de regarder comment les autres le font, et vous apprendrez toujours quelque chose. Mais alors, le copier aveuglément n'est pas bon.