Quel degré de liberté un programmeur devrait-il avoir pour choisir un langage et un framework?

J'ai commencé à travailler dans une entreprise principalement orientée C #. Nous avons quelques personnes qui aiment Java et JRuby, mais une majorité de programmeurs ici aiment C #. J'ai été embauché parce que j'ai beaucoup d'expérience dans la construction d'applications Web et que je me tourne vers les nouvelles technologies telles que JRuby on Rails ou nodejs.

J'ai récemment commencé un projet de création d'une application Web axée sur la réalisation de nombreuses tâches en peu de temps. Le responsable logiciel a dicté que j'utilise mvc4 au lieu de rails. Cela pourrait être OK, sauf que je ne connais pas mvc4, je ne connais pas C # et que je suis le seul responsable de la création du serveur d'applications Web et de l'interface utilisateur frontale.

Ne serait-il pas judicieux d'utiliser un framework que je connais déjà extrêmement bien (Rails) au lieu d'utiliser mvc4? Le raisonnement derrière cette décision était que le responsable technique ne connaissait pas Jruby / rails et qu'il n'y aurait aucun moyen de réutiliser le code.

Contre-arguments:

• Il ne contribuera pas au code et, franchement, il n'est pas nécessaire pour
  ce projet. Donc, peu importe qu'il connaisse ou non JRuby / rails.

• En réalité, nous pouvons réutiliser le code car nous disposons de nombreuses applications java sur lesquelles JRuby peut extraire du code, et inversement. En fait, il a consacré certaines ressources à la conversion d'une bibliothèque Java en C #, au lieu de simplement exécuter la bibliothèque Java sur l'application JRuby on Rails. Tout ça parce qu'il n'aime pas Java ou JRuby

J'ai construit de nombreuses applications Web, mais utiliser quelque chose d'inconnu est en train de créer des difficultés et je ne parviens pas à créer une application géniale aussi rapidement que je suis habitué. Ce serait bien; L’apprentissage des nouvelles technologies est important dans ce domaine. Le problème est que, pour ce projet, nous devons accomplir beaucoup de choses rapidement.

À quel moment un développeur devrait-il être autorisé à choisir ses outils? Cela dépend-il de l'entreprise? Est-ce que mon entreprise craint ou est-ce considéré comme normal? Existe-t-il des pâturages plus verts? Est-ce que je regarde ça de la mauvaise façon?

Je dirais que vous devez parler au chef d'équipe et dire quelque chose comme:

Je sais que vous êtes un magasin .NET, mais j'ai en fait été embauché pour mes compétences en Java / JRubyRails. Je peux construire cette nouvelle application en un temps X en utilisant ces outils que je connais déjà. Je pourrais apprendre le C # / mvc4 comme vous le souhaitez, mais cela prendra >> X fois. Qu'est-ce que vous voulez?

Cela pose la question de « compétences-vous-garous ( en supposant qu'il) -hired-pour » contre « les compétences doivent-maintenant-vous- » et montre aussi que vous êtes prêt à apprendre les nouvelles compétences, mais qu'il se prendre plus de temps pour développer la nouvelle application à mesure que vous débutez dans cet ensemble d’outils. Et vous ne voulez montrer que vous êtes prêt à apprendre de nouvelles compétences. Ne pas être ouvert à l’acquisition de nouvelles compétences est un bon moyen de garantir la cessation de votre emploi lorsque vos compétences ne sont plus nécessaires.

En ce qui concerne votre question à la fin:

À quel moment un développeur devrait-il être autorisé à choisir ses outils? Cela dépend-il de l'entreprise? Est-ce que mon entreprise craint ou est-ce considéré comme normal? Existe-t-il des pâturages plus verts? Est-ce que je regarde ça de la mauvaise façon?

Cela dépend généralement de l'entreprise. Si une entreprise achète des outils MS et normalise tout sur la plate-forme VisualStudio et le framework .NET, cela peut devenir très gênant si un développeur insiste sur l'utilisation de Linux et de C, ce qui est normal. Il peut exister des exceptions dans les cas où la société est moins pointilleuse vis-à-vis des éditeurs, par exemple en laissant les développeurs choisir Vi par rapport à Emacs, à condition que le résultat soit identique. Je sais que certaines entreprises laissent même aux développeurs le choix entre Windows et Linux, mais la langue dans laquelle elles travaillent bénéficie d'une prise en charge et d'une exécution très efficaces pour les deux systèmes d'exploitation.

Pourquoi les entreprises font-elles cela? La cohérence est une des raisons. Il peut être très difficile de déboguer des choses lorsque l’application est un patchwork de binaires construits dans les langages / framework favoris de différents développeurs, construits dans différents outils et testés sur des systèmes très différents. Si tous les développeurs travaillent principalement sur des configurations similaires, ces types de problèmes sont résolus.

Dans votre cas, il semble que vous ayez été embauché pour travailler dans une technologie non standard dans cette entreprise. Cela me semble étrange et vous voudrez peut-être parler à la personne qui vous a embauché pour savoir pourquoi elle le voulait.

À quel moment un développeur devrait-il être autorisé à choisir ses outils?

Quand ils n'ont pas d'impact sur votre équipe.

Est-ce que je regarde ça de la mauvaise façon?

Absolument.

Oui, vous avez un délai court. Oui, vous pouvez le faire plus rapidement dans Rails. Toutefois, l’entreprise dans son ensemble doit déployer et gérer l’application. Si la société dispose d'une base de bons développeurs C #, il sera probablement moins cher (et de meilleure qualité) de disposer d'une application C # à gérer.

Vos administrateurs de base de données et vos autres administrateurs sont probablement familiarisés avec cette pile et disposent de processus pour déployer et mettre à jour cette pile. Même si vous pouvez obtenir le code plus rapidement, cela peut prendre plus de temps une fois que vous avez pris en compte tous les frais généraux nécessaires à la mise en place d'une application Web professionnelle.

N'oubliez pas que vous passerez beaucoup plus de temps à entretenir votre application qu'à l'écrire. Optimiser pour ce coût.

1. Vous avez apparemment été embauché en raison de votre capacité à vous adapter aux "nouvelles" technologies. C # n'est pas différent, à cet égard. Êtes-vous sûr de ne pas vouloir profiter de l'occasion pour apprendre quelque chose de nouveau?

2. ASP.NET MVC est très similaire à Ruby on Rails, à bien des égards.

3. Vous ne serez pas au pas d'un escargot pour toujours. Si vous connaissez déjà ROR, ASP.NET MVC sera un jeu d'enfant pour vous. L'astuce consiste à apprendre le C #.

Arguments pour rester avec Java / JRuby

Les chances sont, votre patron veut que vous produisiez. Ils vous ont embauché pour que vous puissiez ajouter de la valeur à l'entreprise. Assurez-vous qu'ils comprennent qu'en vous forçant à utiliser un framework avec lequel vous n'êtes pas familier, ils vous feront :

1. Produire des résultats plus lentement
2. Créer un code de qualité inférieure

Même les meilleurs programmeurs ont besoin de temps de préchauffage avec de nouveaux langages / frameworks.

Arguments pour l'apprentissage MVC4 et C #

Apprendre de nouvelles langues, c'est bien. Investir dans vos compétences en tant que programmeur ne constitue un risque que si le langage / la plate-forme que vous apprenez va disparaître dans un proche avenir. Avec Microsoft, je ne pense pas que ce soit un problème. C # et MVC ont eu des mises à jour récentes les améliorant tous les deux, avec encore plus de mises à jour dans le pipeline.

Faire de vous, personnellement, un développeur plus complet vous évitera de vous retrouver dans cette situation. La meilleure partie? Votre patron vous paiera pour apprendre ces choses, ce qui signifie que vous serez payé pour gagner plus d'argent.

Le résultat final

Vous pouvez finir par gagner ce combat, mais il vous restera à travailler avec des collègues mécontents. Expliquez simplement les avantages et les inconvénients de chacun à votre responsable et vous en sortirez tous les deux plus heureux.

À quel moment un développeur devrait-il être autorisé à choisir ses outils?

Lorsque ledit développeur est le logiciel en tête.

Certes, vous pouvez (et devriez) plaider en faveur de l’utilisation de la trousse à outils différente si vous êtes préoccupé par la productivité, mais préparez-vous à une réponse qui ne vous plaira pas. Il y a peut-être une bonne bonne raison pour laquelle votre chef d'entreprise souhaite que vous utilisiez une boîte à outils spécifique, que ce soit pour la compatibilité avec l'architecture actuelle, pour des problèmes de maintenance, pour des problèmes de licence, etc.

BTW, la phrase

avec un accent sur faire beaucoup de choses dans un court laps de temps

est responsable de plus de brûlures d'estomac et de chaos dans l'industrie du logiciel que n'importe quoi d'autre.

Je remarque que vous ne dites pas que vous avez été embauché en tant que programmeur JRuby ou Java.

Voici pourquoi vous avez été embauché: "Parce que j’ai beaucoup d’expérience dans la construction d’applications Web et que je me tourne vers de nouvelles technologies telles que JRuby on Rails ou nodejs."

En d'autres termes, ils aiment votre expérience Web et votre volonté d'apprendre de nouvelles technologies.

Maintenant, ils vous demandent d'utiliser votre expérience Web et d' apprendre une nouvelle technologie.

La question est donc de savoir si vous allez le faire ou non.

La plus grosse dépense en logiciel est dans la maintenance de celui-ci

J'ai lu que la dépense la plus importante (80%) concerne la maintenance des logiciels. Le développement initial ne représente que 20% du coût total du développement.

J'ai lu un cas concernant un développeur qui a développé du code et des commentaires dans sa langue maternelle (pas l'anglais) et lorsque les autres membres de l'équipe sont allés améliorer et maintenir le code, c'était presque impossible car le langage (pas n'importe quel langage de programmation) était étranger pour eux.

De même, si vous développez du code dans un langage de programmation de votre choix, il sera difficile à gérer pour les autres membres de l'équipe.

Solution: Programmation par paires

Pensez à demander à vos employeurs de vous mettre en relation avec une autre personne connaissant le langage de programmation requis et pouvant travailler ensemble. Vous pouvez apprendre les uns des autres et si l'un de vous quitte la société, l'autre connaît le code.

Article Wikipedia sur "Programmation en binôme": http://en.wikipedia.org/wiki/Pair_programming

De nombreuses entreprises préfèrent simplement s'en tenir à ce qu'elles ont toujours fait ou à ce qui est "sûr". Il y a une raison pour laquelle Java et PHP sont toujours très populaires. Pour le moment, la recherche de "COBOL" sur Indeed.com renvoie 2144 annonces ... qui devraient vraiment parler pour lui-même. L'industrie ne se soucie pas du bon code, elle se soucie du code car elle peut traire le plus longtemps possible (cela ne veut pas dire que C # est mauvais, ce n'est vraiment pas le cas).

Pensez-y: le code va vous survivre. Il y a de bonnes chances que quelqu'un d'autre maintienne votre code et C # est un pari plus sûr que Node.js et Rails. Cela ne me surprendrait pas si, dans 5 ou 6 ans, le nombre de programmeurs Ruby diminuait de moitié, après que Perl et tout autre langage ayant été considéré à un moment donné comme étant le langage Web "it". Javascript n'est pas susceptible de disparaître, mais nous commençons déjà à le voir utilisé comme une sorte d'ASM (ou même C) du Web - un langage intermédiaire que d'autres langages peuvent compiler pour pouvoir y écrire du code côté serveur. très bien devenir obsolète.

Mon souci principal avec les développeurs qui choisissent comment implémenter leurs objectifs, est qu'ils supposent normalement qu'ils éditeront le code. Regardez cela ainsi, 12 mois plus tard, ils pourraient avoir besoin de changements; vous n'êtes pas disponible (a quitté l'entreprise ou est vraiment occupé par une autre tâche), et un autre développeur doit convertir votre code. Si c'est un magasin C #, alors utiliser leurs outils est un bon travail d'équipe. Les nouvelles technologies devraient être étudiées et mises en œuvre, mais seulement lorsque le responsable estime que le moment est opportun, car il a pour objectif de nombreux objectifs, et pas seulement un.

Retournez-le, s'il vous plaît. Imaginez que vous ayez embauché un développeur Ruby et qu'ils insistent pour mettre en œuvre leur travail dans Asp.net/MVC.

Que leur diriez-vous? Ceci est notre pile, mec. Apprenez à vivre avec.

La règle d'or, ici, c'est celle qui a l'or qui établit les règles.

Il y a plusieurs objectifs contradictoires et le problème est de trouver le meilleur compromis. Nous avons la date limite, nous avons un chef d’équipe qui demande un certain ensemble d’outils, et nous avons un développeur inexpérimenté avec cet ensemble d’outils, mais condamné à produire quelque chose dans un délai (évidemment court).

Il est important de comprendre que le chef d’équipe a probablement de bonnes raisons de demander exactement cet ensemble d’outils (l’un d’eux pourrait bien vous habituer à cet ensemble d’outils pour une raison que vous ignorez peut-être encore). La meilleure chose que vous puissiez faire au premier essai est de déterminer exactement quelles sont ces raisons.

Mis à votre place, j'essaierais de parler au responsable de l'équipe et d'essayer d'expliquer la situation, telle qu'elle est à votre avis, et quelles options et quels résultats (y compris les effets économiques à court et à long terme) seront générés suivant chacune de ces options. Par exemple, un autre développeur plus expérimenté pourrait être chargé de vous coacher, éventuellement avec des sessions de programmation en binôme ou similaires.

À moins que votre chef d'équipe ne soit complètement débile, vous devriez être en mesure de trouver un consensus qui ait du sens en ce qui concerne le projet et les objectifs généraux de l'entreprise.

Bah. Tout le monde a tort.

Devenez un meilleur développeur que les utilisateurs de la plate-forme unique et vous aurez des options beaucoup plus intéressantes que jamais. Donc, pour l'instant, apprenez le MVC. Et à votre rythme, apprenez-en davantage sur les plateformes qui vous intéressent vraiment. Développez vos compétences de nœud. Apprenez du Django. Faites attention à toutes les manœuvres Java ou pré-MVC .NET auxquelles vous êtes exposé, puis fuyez, mais apprenez-en au moins suffisamment pour pouvoir critiquer et expliquer à quel point vous avez pensé à ces préjugés inspirés par la haine, à peine dissimulés. (d'accord, peut-être que je projette là)

Et maintenant pour le conseil important. Si vous continuez à perfectionner vos spécialités tout en diversifiant votre expertise dans d'autres domaines, vous serez éventuellement dans un endroit où vous pourrez trouver du travail à tout moment de l'année en moins de deux semaines, dans n'importe quelle grande ville surtout intéressant au moins la moitié du temps. Lorsque vous vous trouvez dans cet endroit, ne vous contentez pas de ces emplois, où ils disent vouloir cela, et dès le deuxième jour, ils vous feront CELA, sans espoir de sursis à long terme. Juste expliquer poliment et présenter des excuses, mais non, vous ne vouliez vraiment pas faire CELA et vous en avez dit autant lors de votre entretien et ensuite! @ le fait qu'ils ont mal présenté la position et refusent de le reconnaître.

Mais croyez-moi, trouver un nouveau poste est toujours mieux que d'être énervé et malheureux pendant plus de 5 minutes. Mais bien sûr, vous devez d’abord payer vos cotisations pour pouvoir le faire. Certaines personnes ne le feront jamais. C'est pourquoi ils veulent tout ce qu'ils connaissent le mieux. Et bien sûr, les autres réponses ne sont pas vraiment fausses. Il est logique qu'un magasin .NET soit associé à .NET s’il doit maintenir la bêtise.

Bien entendu, ce qui n’a aucun sens est de savoir pourquoi ils se diversifieraient avec un développeur Rails / JS / UI et lui demanderaient uniquement de créer des applications MVC. Mais pour l'instant. Vous devrez peut-être le ramasser et payer votre cotisation. Et comme je l'ai dit dans les commentaires, MVC n'est vraiment pas si mal. Un très mauvais choix étant donné toutes les options mais certainement pas le pire. C'est assez simple, ne jette pas 10 000 couches d'abstraction au-dessus de tout ce qui se passe réellement, et ne se fait pas si tordu avec le côté client que vous maudriez les noms des ingénieurs MS responsables si quelqu'un pouvait être dérangé les apprendre.

Rendez-vous à cet endroit où vous pouvez partir quand vous le souhaitez si vous ne l’avez pas déjà fait et vous pourriez même vous rendre compte que vous avez un œil plus sceptique sur ce que vous aimez actuellement. Vous pourriez même vous retrouver à ne pas aimer les rails autant que moi. Non pas que Ruby a un problème (à part son interprète bien sûr).

Selon votre situation, il peut être dangereux de supposer que vous savez pourquoi ils vous ont embauché, et encore plus de supposer que votre supérieur hiérarchique le sait et convient qu'embaucher des personnes possédant vos compétences est une bonne idée.

Je vous demanderais de suivre les conseils ci-dessus et de vous expliquer pourquoi vous devriez utiliser JRuby au lieu de C #. Peut-être que votre argument et vos échéances signifient qu'il est logique de rompre avec les anciennes méthodes. Je ne voudrais pas simplement supposer que tout va bien, donner le responsable ou expliquer les faits et les laisser prendre la décision, c'est ce pour quoi ils sont payés, plus un peu d'ACY.

À mon avis, l’un des éléments qui différencient les bons développeurs des meilleurs est leur capacité à s’adapter aux nouvelles technologies. Nous vivons dans un monde en évolution rapide où la technologie de pointe d'aujourd'hui deviendra obsolète demain. Par conséquent, un développeur qui ne veut pas s'adapter est d'une utilité limitée pour l'entreprise. Ce serait bien, sinon pour un fait, il est vraiment difficile de recruter et de recruter de bonnes personnes. Quand une entreprise trouve son joyau, elle planifie à long terme.

J'ai vu des entreprises embaucher hors de leur champ technologique et elles le font pour exactement la même raison. Ils veulent avoir la main sur de grands développeurs, même si cela implique d'attendre qu'ils s'adaptent aux nouvelles technologies.

Maintenant à votre situation. En tant que nouveau membre du groupe, je ferais très attention à ce que je dis et ne le dis pas à mes supérieurs. Bien sûr, vous vous en tirerez beaucoup en partant du principe que vous êtes toujours en train de vous adapter à votre nouvel environnement. Cependant, saper l'autorité et la persévérance obstinée à l'égard de votre technologie préférée ne feront que faire croire à vos supérieurs qu'ils ont commis une erreur en vous embauchant et que vous n'êtes pas disposé à quitter votre zone de confort.

Ce que vous allez choisir dépend de vous, mais je vous suggérerais d'essayer d'apprendre de nouvelles technologies. Cela ne fera pas mal, je le promets.

Je vais supposer que vous avez été honnête dès le début de votre entretien concernant votre manque de connaissance de C #, car si vous ne l'étiez pas, vous pourriez vous retrouver dans une position très précaire d'un point de vue juridique.

Les bons programmeurs connaissent la programmation. Bien que personne ne puisse évidemment être au courant de toutes les langues et de tous les cadres, il existe des points communs considérables entre la plupart d'entre elles. À moins que l'on vous demande de travailler dans une langue extrêmement différente de ce qui constitue le grand public de nos jours (Lisp, par exemple), un bon programmeur devrait être capable de s'adapter.

Naturellement, il y a une courbe d'apprentissage. Si l'employeur vous a embauché, il doit avoir confiance en votre capacité à suivre cette courbe dans un délai raisonnable (encore une fois, en supposant que vous avez été honnête dès le départ en ce qui concerne l'absence de connaissance de C #). Le langage C # emprunte énormément à Java et, de manière plus générale, la plupart des langages de programmation basés sur des classes sont fondamentalement assez similaires (vous avez mentionné node.js, qui repose sur ECMAScript, un langage basé sur un prototype. à l'aise avec d'autres paradigmes de programmation.

Les bons programmeurs doivent, en plus d'être flexibles, être désireux d'apprendre de nouvelles choses. En développement logiciel, vous apprenez généralement ou vous perdez votre pertinence.

Bien entendu, votre employeur, supposant qu’il savait que vous ne connaissiez pas C #, doit vous rencontrer à mi-chemin. Si vous êtes désireux d'apprendre, ils doivent vous donner le temps et les ressources nécessaires pour le faire. Il est injuste et stressant de vous jeter au plus profond de vous. Vous devez vous asseoir et avoir une discussion calme et rationnelle avec votre supérieur. S'ils le veulent en C #, ils doivent être prêts à accepter le fait que vous travaillerez sur une courbe d'apprentissage et il serait injuste pour eux de vous imposer des délais serrés. Si les échéances ne sont pas flexibles et si elles revêtent une grande importance stratégique, elles doivent être prêtes à vous laisser une marge de manœuvre pour accomplir le travail dans les délais impartis. S'ils en ont besoin pour être dans la langue la plus utilisée dans leur bureau, vous pouvez alors demander à le mettre en œuvre maintenant dans ce que vous ' Familiarisez-vous avec le respect des délais, puis ré-implémentez-le en C # lors de votre prochain projet. Cela vous permettra de mettre le logiciel en conformité avec les exigences internes une fois que celui-ci sera conforme aux exigences externes. Comme je l'ai dit, la plupart des langages les plus couramment utilisés aujourd'hui ont beaucoup de points communs, c'est donc surtout les détails de la mise en œuvre.

Vous devez être prêt à accepter tôt ou tard votre travail dans un magasin C # et vous devez donc avoir C # sous votre ceinture.

Ils ne sont peut-être pas satisfaits de la manière dont tout le monde utilise MVC dans l'environnement .NET. Il pourrait y avoir trop de traitement comme des formulaires Web. Ce n'est pas différent quand une personne ayant une formation en procédures commence en POO, met tout dans une grande classe et continue comme si de rien n'était.

Ce premier projet n'est pas la situation idéale car ils veulent que cela soit fait rapidement. Familiarisez-vous autant que possible avec .NET et commencez à créer des fonctionnalités le plus rapidement possible. Vous n'allez pas aimer votre façon de faire les choses, essayez juste de garder à l'esprit que vous allez commencer à refactoriser ces choses et à appliquer vos compétences dans une autre langue.

Espérons que votre façon d’utiliser MVC4 (en supposant que tout le monde ne le fait pas correctement) dans un style plus Ruby attirera et dissipera tout le monde de la mentalité de Webforms.