Devrais-je continuer à coder en autodidacte ou apprendre à coder de manière professionnelle? [fermé]

Dernièrement, j’ai eu un travail professionnel, j’ai passé du temps avec d’autres programmeurs et je me suis fait des amis dans l’industrie. La seule chose, c'est que je suis 100% autodidacte. Cela a fait que mon style a été très différent de celui de ceux qui sont correctement formés. Ce sont les techniques et l'organisation de mon code qui sont différentes.

C'est un mélange de plusieurs choses que je fais. J'ai tendance à associer plusieurs paradigmes de programmation. Comme fonctionnel et OO. Je me penche davantage sur le côté fonctionnel que sur OO, mais je vois l'utilisation de OO quand quelque chose aurait plus de sens en tant qu'entité abstraite. Comme un objet de jeu. Ensuite, je vais aussi la voie simple lorsque vous faites quelque chose. Quand au contraire, il semble que parfois le code que je vois des programmeurs professionnels est compliqué pour le plaisir de le voir! J'utilise beaucoup de fermetures. Et enfin, je ne suis pas le meilleur commentateur. Je trouve plus facile de lire mon code que de lire le commentaire. Et dans la plupart des cas, je finis par lire le code même s’il ya des commentaires. De plus, on m'a dit qu'à cause de la simplicité avec laquelle j'écris mon code, il est très facile de le lire.

J'entends des programmeurs formés professionnellement parler sans cesse de choses comme les tests unitaires. Quelque chose que je n'ai jamais utilisé auparavant, alors je n'ai même pas la moindre idée de ce qu'ils sont ou de leur fonctionnement. Des tas de traits de soulignement "_", qui ne sont pas vraiment mon goût. La plupart des techniques que j'utilise viennent directement de moi, ou de quelques livres que j'ai lus. Je ne sais rien de MVC, j'en ai souvent entendu parler avec des choses comme backbone.js. Je pense que c'est un moyen d'organiser une application. Cela me confond cependant, car j’ai maintenant créé mes propres structures organisationnelles.

C'est un peu pénible. Je ne peux absolument pas utiliser d'applications modèles lorsque j'apprends quelque chose de nouveau, comme avec Quickly d'Ubuntu. J'ai du mal à comprendre le code que je peux dire, c'est celui d'une personne formée La programmation OO complète laisse vraiment un mauvais goût dans ma bouche, pourtant cela semble être ce que TOUT LE MONDE utilise strictement.

Je ne suis plus aussi confiant dans l'apparence de mon code, ni à me demander si je vais provoquer des étincelles lorsque je rejoindrai une entreprise ou que je contribuerais à des projets open source. En fait, j'ai plutôt peur du fait que les gens vont éventuellement consulter mon code. Est-ce juste quelque chose de normal qu'un programmeur traverse ou devrais-je vraiment chercher à changer mes techniques?

En fait, je suis plutôt effrayé par le fait que les gens vont éventuellement vérifier mon code.

Bien. Etre conscient que les gens vont regarder votre code vous incitera à essayer plus fort.

La programmation est devenue un domaine incroyablement vaste. Il existe des dizaines de sujets, d’outils, de niches et de spécialisations, dont certains sont des carrières à part entière. Il y a énormément à apprendre et à savoir, et lorsque vous travaillez avec d'autres programmeurs, il y aura toujours des choses que vous savez ou pas. C'est une bonne chose.

Si vous craignez que votre expérience soit incomplète, vous pouvez prendre de nombreuses mesures pour y remédier par le biais d'une éducation formelle et d'une collaboration avec des experts qualifiés. Mais on dirait que vous craignez qu'il y ait un jalon quantifiable après lequel les gens se disent: "Bon, maintenant que je maîtrise ça, je suis officiellement programmeur". Il n'y a pas une telle étape. J'ai certainement eu des moments où je pensais "oui, maintenant je vais quelque part" après avoir appris quelque chose de nouveau, mais il n'y a pas de liste magique de choses que vous devez savoir et faire pour vous appeler un programmeur.

Je connais beaucoup de choses sur la programmation, j'ai utilisé une douzaine de langages dans de nombreux projets, et pourtant le sous-ensemble de connaissances en programmation que je peux appeler moi-même est minuscule. Et j'aime ça. Franchement, un programmeur n'est pas ce que vous êtes. Un programmeur est quelque chose que vous apprenez constamment à être.

Faites un inventaire honnête de vos compétences, de vos forces et de vos faiblesses. Obtenez les commentaires de personnes plus expérimentées que vous. Recherchez des postes qui correspondent assez bien à votre position actuelle, mais n’ayez pas peur de chercher des emplois qui dépassent un peu votre maîtrise actuelle. Si vous ne prenez que des emplois pour lesquels vous connaissez déjà tout, vous n'apprendrez jamais au travail.

Lorsque vous commencez à développer des applications en coopération avec d'autres développeurs, certains de ces problèmes de style personnels vont vous gêner.

Si vous commencez à travailler dans un magasin qui utilise des traits de soulignement, vous allez les utiliser. Tout le monde, quel que soit son passé, respecte la norme de l’atelier en matière de style de codage.

À moins que votre style de codage ne soit extrêmement évident, vous feriez mieux de vous habituer à écrire des commentaires clairs et concis expliquant le fonctionnement de votre code, afin que les autres développeurs puissent le suivre.

Si vous ne connaissez rien aux tests unitaires, achetez un bon livre. Il y a beaucoup de bons livres sur les tests unitaires. Même chose avec MVC.

Les développeurs de logiciels professionnels savent comment bien jouer avec les autres, sans pourrir le bac à sable. Les meilleurs savent lire et écrire du code quel que soit leur style.

La programmation comporte une composante artistique et une composante disciplinaire. La composante artistique consiste à concevoir les meilleures approches et à les mettre en œuvre; la discipline consiste à s'assurer que vous l'avez bien fait et que les autres peuvent comprendre votre code et l'améliorer si nécessaire.

Le volet artistique est amusant: vous le faites parce que vous l’aimez. Naturellement, c'est la partie que vous apprenez vous-même en premier.

La composante discipline est plus une nuisance: vous le faites par nécessité. C'est pourtant un élément essentiel du travail en équipe: vous ne pouvez pas vous en passer, du moins dans une certaine mesure. Une fois que votre code est intégré à celui de vos coéquipiers, votre flexibilité pour "changer les choses à volonté" prend un plongeon. Cependant, vous avez besoin d'une capacité à modifier votre code en toute confiance en réponse à l'évolution des exigences ou à la résolution des bogues. C'est là qu'interviennent divers tests "ennuyeux": avec de nombreux tests en place, il est facile de vérifier si votre dernier changement casse les choses ou non.

Le style de code gagne également en importance, car adhérer à un style commun facilite la lecture du code pour tout le monde. Dans les grandes entreprises, vous trouverez des tâches nocturnes qui testent automatiquement le respect des normes de codage et vous envoient des avertissements par courrier électronique lorsque vous vous écartez.

Pour revenir à votre question, se concentrer sur la composante artistique est un début naturel du développement du programmeur. Cela peut prendre plusieurs années de travail dans l'industrie avant de commencer à apprécier le volet discipline. Vous n'avez cependant pas besoin de chercher activement à "changer vos techniques": elles se métamorphoseront naturellement au cours du processus de travail en équipe.

A votre question, vous devriez toujours chercher à modifier votre technique, à adopter le projet unique et la technologie émergente.

L'attitude de @ assfallows est "Franchement, un programmeur n'est pas ce que vous êtes. Un programmeur est quelque chose que vous apprenez constamment à être." est vraiment la fin du codage.

C'est génial que vous remarquiez des domaines dans lesquels vous faites quelque chose de différent des autres, surtout quand vous voyez que c'est une norme. Vous avez repéré les tests unitaires et MVC - et vous devez maintenant en apprendre davantage sur eux. Voyez comment ils fonctionnent, ce dont vous avez besoin pour les implémenter et essayez de savoir quand la mise en œuvre est bonne.

Il s’agit d’un domaine en constante évolution, caractérisé par de nouvelles langues et de nouveaux modèles. Si vous êtes à l'aise avec l'aspect codage, commencez par examiner la partie conception. Apprenez ce qui les rend bons et quand les utiliser.

Rejoindre une équipe est certainement un avantage non négligeable - vous avez toujours besoin que d'autres personnes examinent votre code pour repérer les zones que vous avez pressées ou auxquelles vous n'avez pas pensé toutes les implications.

Vous n'avez pas besoin d'être un plus grand commentateur. Mais vous devriez être un bon partisan (oui, commencez à utiliser une sorte de VCS - je recommande Git).

Le style est une chose qui évolue TOUJOURS. Ne t'inquiète pas pour ça. Vous apprendrez ce qu'est un code réutilisable et ce qui ne l'est pas. Mais vous devez pratiquer et obtenir de l'aide pour cela.

Essayez d’aider certains projets Open Source sur Github. Certaines personnes sont vraiment gentilles là-bas et essaieront de vous aider. C'est le meilleur conseil que je puisse vous donner.

En fait, je suis plutôt effrayé par le fait que les gens vont éventuellement vérifier mon code. Est-ce juste quelque chose de normal qu'un programmeur traverse ou devrais-je vraiment chercher à changer mes techniques?

Comment sauriez-vous quoi changer sans les commentaires de programmeurs plus expérimentés?

Demander à d’autres personnes d’examiner votre travail peut être décourageant, en particulier les premières fois, mais c’est le meilleur moyen d’obtenir les critiques constructives dont vous avez besoin pour améliorer vos compétences. Il existe un site SE pour les critiques de code que vous pouvez trouver utile. Demander à des amis intelligents d'examiner votre code est un autre moyen efficace d'obtenir des commentaires.

Le plus important est de développer la flexibilité. Plus vous maîtriserez les concepts fondamentaux, plus vous serez réactif dans tous les langages, approches de programmation, styles et environnements.

La maîtrise consiste moins à apprendre tout / quelque chose / qu'il y a à apprendre, et plus à apprendre / comment / comment s'y prendre pour résoudre un problème, dans diverses situations.

Et la meilleure prescription pour cela est la pratique. Vous devriez toujours avoir un projet. si vous êtes entre deux concerts rémunérés, prenez un jouet personnel. Temps libre un week-end? Travaillez dans le «monde des salutations» pour une langue ou une plateforme que vous n'avez jamais utilisée auparavant. Cherchez des moyens d'apprendre beaucoup à la fois. Par exemple, créez quelque chose dans Google App Engine et vous apprendrez simultanément les bases de données Python, BigTable et orientées colonnes. Vous obtiendrez également une bonne dose de style Google "professionnel".

Un bon général sait comment appliquer ses tactiques apprises et son expérience acquise sur une grande variété de terrains. On dirait que vous avez de la tactique et de l’expérience, mais vous devez affronter un terrain inconnu. C'est probablement la meilleure façon de déterminer ce que vous savez et ce que vous devez apprendre par la suite.

Et si vous recherchez un style "professionnel", prenez des projets "professionnels". Recherchez un projet open-source que vous aimez, affectez-vous un changement à effectuer et définissez-le. Préparez-vous aux critiques loufoques, mais rappelez-vous que la majorité des personnes dans ce domaine ne sont pas arrivées où elles sont pour avoir des compétences sociales harmonieuses. Le but est de vous exposer au maximum de ce que vous voulez être. Et vous devez vous construire assez bien pour le faire vous-même. Aucune classe ne peut vraiment vous apprendre. En fait, il y a trop de classes à apprendre aujourd'hui et pas assez de compétences réelles dans le monde réel.

Je ne suis plus aussi confiant dans l'apparence de mon code, ni à me demander si je vais provoquer des étincelles lorsque je rejoindrai une entreprise ou si je contribuerais à des projets open source. En fait, je suis plutôt effrayé par le fait que les gens vont éventuellement vérifier mon code. Est-ce juste quelque chose de normal qu'un programmeur traverse ou devrais-je vraiment chercher à changer mes techniques?

À mon avis, vous n'avez pas à vous soucier de ce que les autres pensent de votre code si vous vous concentrez sur des mesures objectives de sa qualité. Est-ce

• Correct?
• Compréhensible?
• Maintenable?
• Efficace?

En tant que premier principe, votre objectif doit toujours être de vous concentrer sur les qualités objectives plutôt que sur les opinions des autres. Se concentrer sur les opinions des autres est le chemin qui mène à la médiocrité et, à mesure que vous vivez, à l'anxiété.

La seule raison d'être préoccupé par les opinions des autres est de pouvoir bien s'y intégrer socialement (ou dans un environnement de travail). Si vous avez comme objectif d'améliorer les qualités objectives de votre travail, vous n'avez pas besoin de vous sentir effrayé par la réaction des autres - ce ne sont que des occasions d'apprendre ou, au pire, des détails pratiques à traiter. .

Sois honnête avec toi-même!! Continuez à apprendre et à apprécier ce que vous faites.

Tu me fais penser à moi-même après être allé au collège pour devenir ingénieur en logiciel. Si vous voulez être programmeur, je vous conseillerais de prendre position. Vous allez devoir commenter votre code, écrire des tests unitaires, comprendre parfaitement le code orienté objet. Mais pour l'instant, vous n'avez aucune raison réelle de le faire. Tant que vous travaillez juste sur de petits projets personnels. Où vous ne devez répondre à personne sauf à vous-même. En tant que développeur, vous ne grandirez plus.

En prenant en charge de grands projets sur lesquels travaillent beaucoup de personnes et en ayant à répondre à des questions de gestion telles que "Cette version est-elle sans bug? Parce que nous allons le divulguer au client". Vous grandirez en tant que programmeur / ingénieur. Vous aurez des coups durs. Vous pouvez trouver les choses que vous avez mentionnées plus utiles et de nouvelles choses que personne ne pensait auparavant. Tu vas grandir.

Même mon collège n'a pas réussi à m'apprendre ces choses même s'ils ont essayé.

Pour les tests unitaires, recherchez Développement piloté par les tests.

Pour Commenter, pensez au code que vous avez écrit après votre départ. Et le temps que d’autres personnes passeront à l’ingénierie inverse.

Pour les langues orientées objet. Comprenez-le au moins. C'est un outil que vous pouvez utiliser pour résoudre les problèmes de manière plus lisible.

Bonne chance: D

Bref, la meilleure façon d'apprendre est généralement traîner avec quelqu'un que vous pouvez apprendre de . Si vous estimez que vos compétences ne sont pas à la hauteur, sortir avec des gens meilleurs que vous est ce que vous pouvez faire de mieux. Certainement beaucoup mieux que de se retirer et de s’isoler davantage.

Cependant, je pense que vous dressez un tableau très simplifié et trompeur. Loin de tous les programmeurs "professionnellement enseignés" sont vraiment bons. Le simple fait de faire quelque chose ne signifie pas nécessairement que c'est la bonne chose à faire.

Et beaucoup (mais pas tous) ce que vous dites ressemble vraiment à celui qui pourrait leur apprendre un tour ou deux.

Je me penche davantage sur le côté fonctionnel que sur OO, mais je vois l'utilisation de OO quand quelque chose aurait plus de sens en tant qu'entité abstraite.

Cela me semble bien. Les meilleurs codeurs sont ceux qui utilisent le bon outil pour le travail. Je choisissais toujours quelqu'un qui connaissait les deux paradigmes et utilisait chacun d'eux lorsqu'il était logique de choisir quelqu'un qui n'utilisait religieusement qu'un seul paradigme.

Ensuite, je vais aussi la voie simple lorsque vous faites quelque chose. Quand au contraire, il semble que parfois le code que je vois des programmeurs professionnels est compliqué pour le plaisir de le voir!

Encore une fois, la simplicité est bonne . Ne faites pas votre code complexe jusqu'à ce qu'il ait besoin d'être complexe. Certaines personnes n'ont tendance à faire des choses complexes d'une idée peu judicieuse de l' élégance, ou parce que « nous aurons besoin de cette fonctionnalité supplémentaire plus tard. » En règle générale, il est préférable de faire la chose la plus simple qui résout votre problème.

J'utilise beaucoup de fermetures. Bien. C'est pourquoi ils sont là. Ils effraient certaines personnes qui se sont retrouvées coincées dans les années 90 et le modèle quasi-OOP dépassé de Java, mais c'est vraiment leur problème.

Et enfin, je ne suis pas le meilleur commentateur.

Ce qui devrait être commenté et comment est hautement subjectif. Il n'y a pas vraiment de "vrai" ou de "faux", mais lorsque vous travaillez en équipe, il est important d'écrire du code que toute l'équipe, et pas seulement l'auteur du code, peut comprendre. Et parfois, des compromis doivent être faits pour se conformer au style de codage de l'équipe. Cela ne signifie pas nécessairement que vous devriez écrire plus de commentaires, cela signifie simplement que c'est une chose sur laquelle vous et votre équipe devrez vous mettre d'accord.

J'entends des programmeurs formés professionnellement parler sans cesse de choses comme les tests unitaires. Quelque chose que je n'ai jamais utilisé auparavant, alors je n'ai même pas la moindre idée de ce qu'ils sont ou de leur fonctionnement.

Eh bien, demandez-leur. :) Tester votre code est essentiel, et les tests unitaires sont un outil populaire et utile pour cela.

Des tas de traits de soulignement "_", qui ne sont pas vraiment mon goût.

Comme pour les commentaires, cela est subjectif et dépend de la langue. En C et C ++, il lowercase_with_underscoresexiste une convention de dénomination assez commune. Dans de nombreuses autres langues, vous ne verrez pratiquement jamais de soulignement. Mais au bout du compte, ce n'est vraiment pas important. Qu'une fonction soit appelée write_to_logou WriteToLogne va pas réellement faire la différence. Il va falloir que quelqu'un suce et se conforme à ce que l'équipe a convenu de faire.

Je ne sais rien de MVC, j'en ai souvent entendu parler avec des choses comme backbone.js. Je pense que c'est un moyen d'organiser une application. Cela me confond toutefois, car j’ai maintenant créé mes propres structures organisationnelles.

Comme avec les tests unitaires, n'arrêtez jamais d'apprendre. Vous travaillez avec des personnes qui savent des choses que vous ne connaissez pas et qui viennent d'un milieu différent de vous. Apprendre les uns des autres. Il y a clairement des choses que vous pouvez leur apprendre, mais il y a aussi des choses que vous ne savez pas, ou dont vous n'avez jamais entendu parler, qu'ils peuvent vous apprendre. Cela ne signifie pas que vous (ou eux) êtes un mauvais programmeur. Cela signifie qu'un bon programmeur est celui qui s'efforce de s'améliorer et d'apprendre des autres.

La programmation OO complète laisse vraiment un mauvais goût dans la bouche

Idem ici, et je suis ce que vous appelleriez une "formation professionnelle" (un diplôme en informatique). Les personnes à qui on enseigne la programmation diffèrent tout autant que les autodidactes. On dirait que vous travaillez avec des personnes qui ont vraiment besoin d'apprendre quelques nouveaux trucs.

En fait, je suis plutôt effrayé par le fait que les gens vont éventuellement vérifier mon code. Est-ce juste quelque chose de normal qu'un programmeur traverse ou devrais-je vraiment chercher à changer mes techniques?

Tous les deux. Bien sûr, il est effrayant de demander aux autres de regarder (et de juger) ce que vous avez fait. Mais c'est aussi très instructif. Ils peuvent vous dire ce qu'ils auraient fait autrement ou pourquoi ils l'auraient fait autrement. Ils peuvent vous aider à vous améliorer et ils pourraient aussi apprendre quelque chose eux-mêmes. Montrez-leur un code qui résout mieux le problème que ne l'aurait fait leur solution "préférée", et j'espère qu'ils iront "oh, c'est génial. Comment avez-vous su faire cela? Comment appelez-vous cela? Je devrais utiliser cette technique moi-même "

Ce n'est pas une réponse complète, vous en avez déjà plusieurs bonnes. Cependant, certains points me semblent un peu confus et n'ont pas encore été abordés.

C'est un mélange de plusieurs choses que je fais. J'ai tendance à associer plusieurs paradigmes de programmation. Comme fonctionnel et OO. Je me penche davantage sur le côté fonctionnel que sur OO, mais je vois l'utilisation de OO quand quelque chose aurait plus de sens en tant qu'entité abstraite. Comme un objet de jeu.

Pour moi, il semble que vous confondiez la programmation déclarative et impérative , plutôt que la programmation fonctionnelle vs orientée objet. Si vous voulez dire que vous vous penchez vers la programmation déclarative et que vous vous éloignez de l'impératif, c'est une bonne chose. Le déclaratif cherche à supprimer les effets secondaires, ce qui devrait rendre votre code plus facile à comprendre.

Les langages de programmation modernes supportent souvent un modèle de programmation déclaratif. Par exemple, en C #, l’utilisation de Linq donne un style déclaratif, car vous ne dites pas comment obtenir ce que vous voulez; vous ne faites que dire ce que vous voulez.

La programmation OO complète laisse vraiment un mauvais goût dans ma bouche, pourtant cela semble être ce que TOUT LE MONDE utilise strictement.

Les langues modernes sont souvent des langues multi-paradigmes. Il est rare que quelqu'un utilise un langage "pur". De nombreux langages fonctionnels prennent en charge les objets et les effets secondaires. Les langages considérés orientés objet n'imposent souvent pas la contrainte que tout est un objet.

Qu'entendez-vous par OO complet? Je n'ai jamais travaillé sur du code "pur" OO. Peut-être pourriez-vous nous donner plus de détails sur ce que vous n'aimez pas. Une illustration d'un projet open source pourrait aider.

La programmation OO nous offre de nombreuses fonctionnalités pour prendre en charge des éléments tels que: l'abstraction de données, l'encapsulation, la messagerie, la modularité, le polymorphisme et l'héritage. Si je regardais une base de code qui n'en tirait pas parti, cela me laisserait un goût amer.

Réponse courte: oui.

Enseigner vous-même est presque tout bon.
Filtrer avec bon sens, bon conseil.

WRT apprentissage de la programmation professionnelle, oui.
À quoi penses-tu?
Conférences, séminaires, certification, un diplôme?
Chacun a un coût / bénéfice.
Lorsque le retour sur investissement est bon, si vous avez les ressources, allez-y.

Pesez les conseils sur les degrés en considérant la source: les personnes avec ou sans eux ont des intérêts particuliers.
Parlez à une demi-douzaine de chacun.

Le monde universitaire est-il isolé de l'industrie? Souvent.
Un diplôme est-il sans valeur? Dollar sage, difficile à discuter.
Les diplômés gagnent presque toujours plus d'argent, mais faites attention aux prêts universitaires.

Connaissance sage? Peut être.
Si vous détestez l'école, vous n'en sortirez pas plus que ce que vous avez investi.

Si vous estimez qu'un diplôme est un objectif louable pour vous, c'est probablement le cas.

Creusez plus profondément et découvrez le programme d'études, les coûts, l'environnement. Assurez-vous d'avoir l'intérêt, l'engagement, le temps et les ressources. Tu es probablement allé à l'école pendant treize ans, alors qu'est-ce que quatre autres années? Ils seront les plus chers, et la personne principale sur laquelle vous compterez pour en faire le plus précieux, c'est vous.

Les coûts peuvent être assez effrayants, mais ils ne racontent qu'une partie de l'histoire parce qu'il existe de nombreuses subventions et bourses pour le mérite, les besoins et cent autres raisons.

Si vous y allez, choisissez des profs et des têtes intelligents.

Deuxième question - Puis-je utiliser mon propre style?

Vous avez deux questions.

Le premier est dans votre titre. S'il vous plaît voir ma réponse précédente.

La seconde est détaillée dans environ cinq paragraphes où vous décrivez en quoi votre style diffère du style professionnel avec les points énumérés ci-dessous:

• 100% autodidacte.
• Différent dans la technique et l'organisation.
• Mélange de fonctionnel et orienté objet.
• Moins compliqué.
• Beaucoup de fermetures.
• Peu de commentaires.
• Pas de tests unitaires.
• Peu de soulignés.
• Pas de MVC.
• Pas de backbone.js.
• Aucune application de modèle.

En résumé, je pense que vous demandez s’il est bon d’utiliser l’approche Frank Sinatra - "Je l’ai fait à ma façon". Je sens l'ambivalence lorsque vous appelez un professionnel du code des autres utilisateurs, mais vous ne l'acceptez pas. Le style est un problème personnel délicat, et le débat sur ce qu’est un bon code est sans fin et souvent une perte de temps. Certaines questions peuvent être plus faciles si votre groupe utilise une convention de codage écrite. Veuillez vérifier s'il vous plait:

http://en.wikipedia.org/wiki/Coding_conventions

Tuer le code de quelqu'un d'autre est une étiquette, et c'est une autre chose sur laquelle vous devriez travailler avec votre équipe. Mettez votre peau épaisse et espérez qu’elles ne sont pas trop brutales, mais quoi que vous fassiez, n’entrez pas en guerre.

Vous avez commenté l'inquiétude de voir les autres personnes voir votre code. Préparez-vous, car non seulement ils vont le voir, mais ils vont le réécrire et vous dire ce qui ne va pas avec votre style. Vos collègues peuvent être flexibles ou rigides. Quoi qu'il en soit, je vous recommande de ne pas réécrire leur code pour le style ou de faire de chaque point de style une négociation.

Un code uniforme (et une formation uniforme) ont pour objectif d’accroître la rapidité et la productivité du développement et, d’une certaine manière, d’institutionnaliser l’apprentissage des meilleures pratiques. Des problèmes tels que camelCase ou use_underbars peuvent sembler triviaux et mesquins, mais la cohérence présente des avantages.

Veuillez être ouvert aux tests unitaires et au développement piloté par les tests. Lorsque vous êtes seul et que vous ne participez pas à la réalisation de projets contre rémunération, cela ressemble plus à un passe-temps. Vos affaires n'ont pas besoin de s'emboîter avec ce que font les autres. Si votre code plante, ce n'est pas grave. Mais lorsque vous travaillez avec une équipe, le code que vous écrivez peut affecter l’ensemble de l’équipe, en particulier s’il parvient aux clients.

De même, si votre équipe utilise MVC, veuillez en apprendre davantage à ce sujet, en espérant qu'elle provienne des mêmes sources que celles auxquelles elle fait référence. Les méthodes de structuration des programmes peuvent faire une énorme différence, comme l'a montré l'expérience. Encore une fois, prenons l'exemple et le leadership de votre équipe.

Si votre équipe utilise backbone.js, vous l’utilisez aussi. Votre équipe est comme des canards volant en formation. S'aligner ensemble les aide à dépenser moins d'énergie, les rend plus sûres et les aide à se rendre plus efficacement. L'analogie disparaît si vous insistez beaucoup, mais l'utilisation d'outils et de techniques communs et l'alignement sur les décisions des équipes présentent de grands avantages.

Les conseils donnés sont très utiles, mais j'essaie de me rappeler que mon objectif principal est de créer un «logiciel fonctionnel» utile à mes utilisateurs. Mon public n'est généralement PAS un groupe de programmeurs - ce sont des hommes d'affaires prêts à payer pour une solution automatisée (les utilisateurs se moquent des méthodologies OO, des frameworks, des tests unitaires, des commentaires de code, etc., alors ne vous en faites pas trop raccroché dessus.)

J'ai trouvé les idéaux du Manifeste Agile utiles dans ma carrière (www.agilemanifesto.org)

• Individus et interactions sur les processus et les outils
• Logiciel de travail sur une documentation complète
• Collaboration client sur négociation de contrat
• Répondre au changement au sujet d'un plan

Je me rattache complètement à cette question. J'ai exactement les mêmes sentiments et des antécédents très similaires (mais pas exactement les mêmes). Je suis censé avoir une formation professionnelle (ou plutôt académique), donc je suis supposé connaître la programmation OO, etc. La programmation n'était pas mon sujet principal, mais je l'ai fait. J'ai appris le OO dans certains de mes cours et je ne comprenais pas du tout la raison d'être. En fait, la seule fois où j'ai compris OO, c’était lorsque je travaillais dans le commerce et que deux grands mentors l’y ont forcée.

Je suis sûr que mon professeur a été tout aussi brillant, mais vous voyez le réel avantage de la pratique dans un environnement commercial par rapport à la programmation fonctionnelle, mais vous n’avez pas la chance de le voir dans un cours conçu pour fonctionner et enseigner dans quelques mois. . Je n’ai pas eu la chance de travailler sur une structure basée sur MVC, mais je suis sûr que ce sera la même chose, c’est-à-dire que je serai capable de reprendre les concepts à partir d’un livre, mais je comprendrai ses avantages si environnement commercial. Et je suis tout à fait d’accord avec vous, pourquoi utiliser OO, MVC et toute autre structure complexe si vous pouvez résoudre un problème de manière plus simple. Mon conseil est de ne pas craindre le travail, cela vous exposerait à des situations différentes et vous permettrait de comprendre les mêmes choses sous un jour différent.

Bien sûr, j’ai appris la syntaxe et les concepts dans mon parcours universitaire, mais c’est dans le monde commercial que j’ai commencé à apprendre à programmer.