Quelle liberté devrait avoir un programmeur dans le choix d'un langage et d'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 comme C #. J'ai été embauché parce que j'ai beaucoup d'expérience dans la création d'applications Web et parce que je penche vers des technologies plus récentes comme JRuby sur Rails ou nodejs.
J'ai récemment commencé un projet de création d'une application Web avec pour objectif de faire beaucoup de choses en peu de temps. Le responsable du 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 je suis le seul responsable de la création du serveur d'applications Web et de l'interface utilisateur frontale.
Ne serait-il pas logique d'utiliser un framework que je connais déjà très bien (Rails) au lieu d'utiliser mvc4? Le raisonnement derrière la 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 n'est franchement pas nécessaire sur
ce projet. Donc, peu importe qu'il connaisse JRuby/Rails ou non.En fait, nous pouvons réutiliser le code car nous avons beaucoup d'applications Java que JRuby peut extraire du code et vice-versa. En fait, il a consacré quelques ressources pour convertir une bibliothèque Java en C #, au lieu d'exécuter simplement la bibliothèque Java sur l'application JRuby sur Rails. Tout ça parce qu'il n'aime pas Java ou JRuby
J'ai créé de nombreuses applications Web, mais l'utilisation de quelque chose de peu familier provoque une rotation et je ne peux pas créer une application géniale en aussi peu de temps que d'habitude. Ce serait bien; l'apprentissage des nouvelles technologies est important dans ce domaine. Le problème est que pour ce projet, nous devons faire beaucoup de choses rapidement.
À quel moment un développeur devrait-il être autorisé à choisir ses outils? Cela dépend-il de l'entreprise? Mon entreprise craint-elle ou est-ce considéré comme normal? Des pâturages plus verts existent-ils? Suis-je en train de regarder ça dans le mauvais sens?
Je dirais que vous devez parler au chef d'équipe et dire quelque chose comme:
Je sais que vous êtes une boutique .NET, mais j'étais en fait embauché pour mes compétences Java/JRubyRails. Je peux créer cette nouvelle application en [~ # ~] x [~ # ~] quantité de temps en utilisant les outils que je connais déjà. Je pourrais apprendre C #/mvc4 comme vous le souhaitez, mais cela prendra >> X temps. Qu'est-ce que tu veux?
Cela soulève la question des "compétences-vous-étiez-supposément-louées-pour" vs "compétences-dont-vous avez besoin maintenant" et montre également que vous êtes prêt à apprendre les nouvelles compétences, mais que cela prendra plus de temps pour développer la nouvelle application car vous êtes nouveau dans cet ensemble d'outils. Et vous voulez montrer que vous êtes prêt à acquérir de nouvelles compétences. Ne pas être ouvert à l'apprentissage de nouvelles compétences est un bon moyen de s'assurer que votre emploi se termine lorsque vos compétences ne sont plus nécessaires.
Quant à votre question à la fin:
À quel moment un développeur devrait-il être autorisé à choisir ses outils? Cela dépend-il de l'entreprise? Mon entreprise craint-elle ou est-ce considéré comme normal? Des pâturages plus verts existent-ils? Suis-je en train de regarder ça dans le mauvais sens?
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 pourrait devenir très gênant si un développeur insiste pour utiliser Linux et C. C'est normal. Des exceptions peuvent exister lorsque la société est moins pointilleuse sur les éditeurs, comme laisser les développeurs choisir Vi vs Emacs, tant que la sortie est la même. Je sais que certaines entreprises laissent même les développeurs choisir Windows contre Linux, mais le langage dans lequel ils travaillent a un très bon support et des temps d'exécution 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/frameworks préférés de divers développeurs, construits dans différents outils et testés sur des systèmes très différents. Si tous les développeurs travaillent sur principalement 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é pourquoi ils le voulaient.
À quel moment un développeur devrait-il être autorisé à choisir ses outils?
Quand ils n'ont pas d'impact sur votre équipe.
Suis-je en train de regarder ça dans le mauvais sens?
Absolument.
Oui, vous avez un court délai. Oui, vous pouvez le faire plus rapidement dans Rails. Mais l'entreprise dans son ensemble doit déployer et maintenir l'application. Si l'entreprise a une bonne stabilité de développeurs C #, il sera probablement moins cher (et produira une meilleure qualité) d'avoir une application C # à maintenir.
Vos administrateurs de base de données et autres membres du personnel administratif connaissent probablement cette pile et ont des processus en place pour déployer et mettre à jour la pile that. 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 pour qu'une application Web professionnelle soit opérationnelle.
N'oubliez pas que vous allez passer beaucoup plus de temps à maintenir votre application qu'à l'écrire. Optimiser pour ce coût.
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?
ASP.NET MVC est très similaire à Ruby on Rails, à bien des égards.
Vous ne serez pas au rythme 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
Il y a de fortes chances que votre patron veuille 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 que vous ne connaissez pas, ils vous feront:
- Produisez des résultats à un rythme plus lent
- Créer un code de qualité inférieure
Même les meilleurs programmeurs ont besoin de temps de préchauffage avec de nouveaux langages/cadres.
Arguments pour apprendre MVC4 et C #
Apprendre de nouvelles langues, c'est bien. Investir dans vos compétences en tant que programmeur n'est un risque que si la langue/plate-forme que vous apprenez va disparaître dans un proche avenir, et avec Microsoft, je ne pense pas que ce soit un problème. C # et MVC ont tous deux eu des mises à jour récentes les améliorant tous les deux, avec encore plus de mises à jour dans le pipeline.
Vous faire, personnellement, un développeur plus équilibré vous empêchera d'être mis dans cette situation plus jamais. La meilleure partie? Votre patron vous paiera pour apprendre ces choses, ce qui signifie que vous êtes payé pour gagner plus d'argent.
The Bottom Line
Vous finirez peut-être par gagner ce combat, mais vous vous retrouverez à travailler avec des collègues mécontents. Expliquez simplement les avantages et les inconvénients de chacun à votre manager 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 responsable logiciel.
Certes, vous pouvez (et devriez) plaider pour l'utilisation des différentes boîtes à outils si vous êtes préoccupé par la productivité, mais soyez prêt pour une réponse que vous n'aimerez pas. Il peut y avoir une sacrée bonne raison pour laquelle votre responsable souhaite que vous utilisiez une boîte à outils spécifique, que ce soit la compatibilité avec l'architecture actuelle, les problèmes de maintenance, les problèmes de licence, etc.
BTW, la phrase
en mettant l'accent sur la réalisation de beaucoup de choses en peu de temps
est responsable de plus de brûlures d'estomac et de chaos dans l'industrie du logiciel que presque tout le reste.
Je note que vous ne dites pas que vous avez été embauché en tant que programmeur JRuby ou Java.
Voici pourquoi vous avez dit que vous avez été embauché: "[B] car j'ai beaucoup d'expérience dans la création d'applications Web et parce que je penche vers des technologies plus récentes comme JRuby sur 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 de apprendre une nouvelle technologie.
Alors la question est, allez-vous le faire, ou non?
La plus grosse dépense de logiciel est dans sa maintenance
J'ai lu que la plus grosse dépense (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 sur un développeur qui a développé du code et des commentaires dans sa langue maternelle (pas l'anglais) et quand 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 serait difficile pour les autres membres de l'équipe de le maintenir.
Solution: Programmation par paires
Pensez à demander à vos employeurs de vous jumeler avec quelqu'un d'autre qui connaît le langage de programmation requis et vous pouvez travailler ensemble. Vous pouvez apprendre les uns des autres et si l'un d'entre vous quitte l'entreprise, l'autre connaîtra le code.
Article Wikipédia sur la "Programmation par paires": 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 Java et PHP sont toujours très populaires. Pour le moment, la recherche de "COBOL" sur Indeed.com renvoie 2144 listes ... qui devraient L'industrie ne se soucie pas du bon code, elle se soucie du code qu'elle peut traire aussi longtemps que possible (cela ne signifie pas que C # est mauvais, ce n'est vraiment pas le cas).
Pensez-y: le code va vous survivre. Il y a de fortes chances que quelqu'un d'autre maintienne votre code et C # est un pari plus sûr que Node.js et Rails. Cela ne m'étonnerait pas si dans 5 ou 6 ans le nombre de programmeurs Ruby divisés par deux, après tout de même arrivé à Perl et à tout autre langage qui a été considéré à un moment donné le "ça") Javascript n'est pas susceptible de disparaître, mais nous commençons déjà à le voir être utilisé comme une sorte d'ASM (ou même de C) du Web - un langage intermédiaire que d'autres langues peuvent compiler pour écrire du code côté serveur en elle pourrait très bien devenir obsolète.
Ma principale préoccupation avec les développeurs qui choisissent comment implémenter leurs objectifs, est qu'ils supposent normalement qu'ils éditeront le code. Regardez-le de cette façon, 12 mois plus tard, ils peuvent avoir besoin de changements; vous n'êtes pas disponible (quittez l'entreprise ou êtes vraiment occupé sur une autre tâche), et un autre développeur doit battre votre code. Si c'est une boutique C #, alors utiliser leur ensemble d'outils est un bon travail d'équipe. Les nouvelles technologies doivent être étudiées et mises en œuvre, mais uniquement lorsque le responsable pense que le moment est venu, car ils ont l'œil sur de nombreux objectifs et non un seul.
Retournez-le, s'il vous plaît. Imaginez que vous êtes celui qui embauche un développeur Ruby, et ils insistent pour implémenter leur travail dans Asp.net/MVC.
Que leur diriez-vous? Voici notre pile, mec. Apprenez à vivre avec.
La règle d'or, voici, c'est elle qui a l'or qui fait les règles.
Il y a un certain nombre d'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 ce jeu d'outils mais voué à produire quelque chose dans un délai (évidemment court).
Il est important de comprendre que le chef d'équipe a probablement de bonnes raisons pour lesquelles il exige exactement cet ensemble d'outils (dont l'un pourrait en effet être de vous habituer à cet ensemble d'outils pour une raison que vous ne connaissez peut-être pas encore). La meilleure chose que vous puissiez faire lors de la première exécution est de découvrir quelles sont exactement ces raisons.
Dans votre position, j'essaierais de parler au chef d'équipe et d'essayer d'expliquer la situation, telle qu'elle est à votre avis, et les options et les résultats (y compris les effets économiques à court terme et à long terme) qui seront générés suivant chacune de ces options. Par exemple, un autre développeur plus expérimenté pourrait être désigné pour vous coacher, peut-être avec des sessions de programmation par paires ou similaires.
À moins que votre chef d'équipe ne soit un idiot complet, vous devriez être en mesure de trouver un consensus qui a du sens en ce qui concerne le projet et les objectifs généraux de l'entreprise.
Bah. Tout le monde a tort.
Soyez un meilleur développeur que ces personnes à plate-forme unique et vous aurez beaucoup plus d'options intéressantes qu'elles ne le feront jamais. Donc, pour l'instant, apprenez MVC. Et à votre rythme, apprenez-en plus sur les plateformes qui vous intéressent vraiment. Développez vos compétences Node. Apprenez quelques notions de Django. Faites attention à tout ce qui est Java ou les manigances pré MVC .NET auxquelles vous êtes exposé, puis fuyez mais au moins en apprendre suffisamment pour être en mesure de critiquer et d'expliquer combien vous avez pensé à vos préjugés haineux brûlants à peine dissimulés à l'égard de ces plates-formes (d'accord, peut-être que je projette là-bas)
Et maintenant pour les conseils importants. Si vous continuez à perfectionner vos spécialités tout en diversifiant votre expertise dans d'autres domaines, vous finirez par être dans un endroit où vous pourrez trouver de nouveaux emplois à tout moment de l'année en moins de deux semaines dans n'importe quelle grande ville donnée faisant des choses qui sont surtout intéressant au moins la moitié du temps. Lorsque vous vous trouvez dans cet endroit, n'acceptez pas ces emplois où ils disent qu'ils veulent cela et le deuxième jour, ils vous font faire cela sans aucun espoir d'un sursis prévisible à long terme. Expliquez simplement poliment et excusez-vous, mais non, vous ne vouliez vraiment pas faire CELA et en dire autant lors de votre entrevue, puis! le fait qu'ils vous ont dénaturé la position et refusent de le reconnaître.
Mais croyez-moi, trouver un nouveau concert est toujours bien mieux que de devenir sérieusement irrité et malheureux pour une période de 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'une boutique .NET choisisse .NET si elle doit maintenir la bêtise.
Bien sûr, ce qui n'a pas de sens, c'est pourquoi ils se diversifieraient avec un développeur Rails/JS/UI et ne le feraient que des applications MVC. Mais pour l'instant. Vous devrez peut-être le récupérer et payer vos cotisations. 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 tord pas tellement avec le côté client que vous maudiriez les noms des ingénieurs MS responsables si quelqu'un pouvait être dérangé pour les apprendre.
Alors, 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 trouver que vous avez un œil plus sceptique sur les choses que vous aimez actuellement. Vous pourriez même vous détester Rails autant que moi. Pas qu'il n'y ait rien de mal avec Ruby (autre que son interprète bien sûr).
Je vais supposer que vous avez été honnête au début de votre entretien au sujet de votre manque de connaissances en C #, car si vous ne l'étiez pas, vous pourriez être 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 bien connaître tous les langages et cadres, il existe des points communs considérables entre la plupart d'entre eux. À moins qu'on ne vous demande de travailler dans un langage qui diffère massivement de ce qui constitue le courant dominant de nos jours (LISP, par exemple), alors 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 vos capacités à suivre cette courbe dans un laps de temps raisonnable (encore une fois, en supposant que vous avez été honnête dès le départ concernant le fait de ne pas connaître C #). Le langage C # emprunte beaucoup à Java, et plus généralement, la plupart des langages de programmation basés sur des classes sont fondamentalement assez similaires (vous avez mentionné node.js, qui s'appuie sur ECMAScript, qui est un langage basé sur un prototype, vous êtes donc évidemment à l'aise avec d'autres paradigmes de programmation.
Les bons programmeurs devraient, en plus d'être flexibles, être désireux d'apprendre de nouvelles choses. Dans le développement de logiciels, vous apprenez généralement ou vous perdez de votre pertinence.
Bien sûr, votre employeur, en supposant qu'il savait que vous ne connaissiez pas C #, doit vous rencontrer à mi-chemin. Si vous montrez votre désir d'apprendre, ils doivent vous donner le temps et les ressources pour le faire. Vous jeter au plus profond est injuste et inutilement stressant. 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 que vous serez sur une courbe d'apprentissage tout en y travaillant et il serait injuste pour eux de vous imposer des délais serrés. Si les délais ne sont pas flexibles et s'ils sont d'une grande importance stratégique, alors ils doivent être préparés pour vous donner une certaine latitude pour faire le travail dans ce délai. S'ils en ont besoin pour être dans la langue la plus couramment utilisée dans leur bureau, vous pouvez peut-être demander à l'implémenter maintenant dans ce que vous connaissez pour respecter le délai, puis comme votre prochain projet le réimplémenter en C # comme exercice d'apprentissage et pour mettre le logiciel en conformité avec les exigences internes une fois qu'il répond aux exigences externes. Comme je l'ai dit, la plupart des langues les plus couramment utilisées aujourd'hui ont beaucoup en commun, donc cela se résume principalement aux détails d'implémentation.
Vous devez être prêt à accepter tôt ou tard que vous travaillez dans un magasin C # et vous devez donc avoir C # sous votre ceinture.
Selon votre situation, il pourrait être dangereux de supposer que vous savez pourquoi ils vous ont embauché, et plus encore de supposer que votre gestionnaire le sait et convient que l'embauche de personnes avec vos compétences est une bonne idée.
Je demanderais de prendre les conseils ci-dessus et de faire une analyse de rentabilisation pour laquelle vous devriez aller avec JRuby sur C #, peut-être que votre argument et vos délais signifient que rompre avec les anciennes méthodes a du sens. Je ne ferais pas que supposer que tout va bien ou non, donner au manager ou diriger les faits et les laisser prendre la décision, c'est pour cela qu'ils sont payés beaucoup d'argent, plus c'est un peu de CYA.
À mon avis, une des choses qui sépare les bons développeurs des grands 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, si ce n'est pour un petit fait que trouver et embaucher de bonnes personnes est vraiment très difficile à faire et lorsqu'une entreprise trouve son joyau, elle planifie à long terme.
J'ai vu des entreprises embaucher en dehors de leur champ technologique et elles le font exactement pour la même raison. Ils veulent mettre la main sur de grands développeurs, même si cela signifie attendre qu'ils s'adaptent aux nouvelles technologies.
Passons maintenant à votre situation. En tant que nouveau gars dans le groupe, je serais très prudent quant à ce que je dis et ne dis pas à mes supérieurs. Bien sûr, vous vous en sortirez beaucoup en supposant que vous êtes toujours en train de vous adapter à votre nouvel environnement. Cependant, saper l'autorité et la persévérance obstinée envers votre technologie préférée ne fera que faire croire à vos supérieurs qu'ils ont fait une erreur en vous embauchant et que vous n'êtes pas prêt à quitter votre zone de confort.
Ce que vous choisirez dépend de vous, mais je vous suggère d'essayer d'apprendre de nouvelles technologies. Ça ne fera pas de mal, je le promets.
Peut-être qu'ils ne sont pas satisfaits de la façon 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 lorsque quelqu'un avec une expérience procédurale commence dans la POO, met tout dans une grande classe et continue comme d'habitude.
Ce premier projet n'est pas la situation idéale car ils veulent que cela se fasse si rapidement. Mettez-vous à jour sur .NET autant que possible et commencez à lancer des fonctionnalités aussi rapidement que possible. Vous n'aimerez pas la façon dont vous faites les choses, essayez simplement de garder à l'esprit que vous commencerez à refactoriser ce truc 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 tout à fait correctement) dans un style plus rubis va se propager et casser tout le monde loin de la mentalité des Webforms.