Un ordre d'entreprise pour passer à un certain IDE est-il un drapeau rouge? [fermé]


80

J'ai récemment rejoint une startup en pleine croissance. Au cours des 3 derniers mois, l’équipe de développement est passée de 4 à 12 personnes. Jusque-là, elle laissait beaucoup de côté pour ce que les développeurs faisaient auparavant. En fait, l’un des attraits que j’ai initialement attiré au sein de la société est que la plupart des programmeurs utilisent Linux, ou le système d’exploitation qu’ils jugent le mieux adapté à leurs efforts.

Maintenant, les ordres, sans discussion, sont descendus que tout le monde doit passer à Eclipse. Un bon éditeur. Je préfère SublimeText2, mais c'est juste mon goût personnel.

Soyons clairs: nous sommes une équipe JS qui utilise Backbone et Eclipse n’est tout simplement pas bon pour comprendre le code Backbone. Cela signifie que les membres de l'équipe qui utilisent un / good / IDE (PHP Storm) doivent recommencer à faire beaucoup de recherches pour trouver-oh-attendre-où-était-je-trois-étapes-il y a genre de choses au lieu de simplement ctrl + clic et utilisation de l’arrière / de l’avant - diminuant probablement la productivité de 15% et le plaisir de 50% ...

Est-ce un drapeau rouge? Il semble capricieux et déraisonnable de contrôler de dire aux développeurs (non-MS) quels IDE ou ensembles d'outils à utiliser s'ils sont déjà installés et productifs.


7
Quel est votre processus de construction? Ce qui doit être mis en place pour que les caractères que vous tapez devienne un code binaire destiné aux clients.

22
C'est une start-up. Si la direction prend unilatéralement une décision telle que celle d’affecter le développement, sans discussion, cela pourrait être un drapeau rouge majeur, peu importe de quoi il s’agit.
joshin4colours

29
Non - il y a une myriade de raisons de passer à un seul IDE: licences, processus, continuité, cohérence ...
Wonko the Sane

55
Une entreprise en pleine croissance qui essaie d'établir rapidement une norme est une solution intelligente dans mon livre (peu importe ce que c'est)! Mettez tout le monde sur la même page et construisez une expertise avec un IDE commun. Ensuite, l'équipe devient plus efficace car tout le monde peut s'entraider et partager du code plus facilement sans se soucier de la largeur de la tabulation, de l'encodage, etc.
Yanick Girouard

23
Eclipse est un environnement complet, pas seulement un éditeur. Peut-être le service informatique a-t-il découvert que la gestion de chaque flocon de neige spécial dans une entreprise en croissance devenait une tâche énorme et onéreuse et qu'il fallait normaliser. Peut-être il y a un outil dans la gestion de l'écosystème Eclipse que vous souhaitez utiliser bientôt. Peut-être que 12 éditeurs de formatage automatique différents ont pissé sur votre référentiel et ont généré des constructions supplémentaires. Des outils éventuellement sans licence "de chez eux" inquiètent les responsables qui ne veulent pas être poursuivis en justice. Peut-être que vous êtes le nouveau type, vous attendez-vous vraiment à être consulté sur les grandes décisions en matière d'informatique et de développement? Pourrait être un million de raisons, toutes saines d'esprit.
Patrick Hughes

Réponses:


92

"Maintenant, les ordres, sans discussion , sont descendus que tout le monde doit passer à Eclipse."

Je pense que c'est le drapeau rouge. Votre équipe est l’expert en développement de logiciel et celle qui sera touchée par la décision. Pourtant, vous n’avez pas eu le droit de dire un mot dans la discussion qui a abouti à cet ordre?

Cela ressemble à une gestion excessive par des patrons pointus. La personne / l'équipe responsable de la prise de décision a-t-elle un aperçu pertinent de cette décision?


Étant donné que les décideurs sont suffisamment qualifiés pour prendre une telle décision, ne pas demander l'avis de l'équipe de développement présente au moins deux inconvénients:

  • L'équipe ne se sent pas impliquée. L'implication de l'équipe devrait être une priorité pour la gestion. Je ne voudrais pas travailler en tant que développeur quelque part où mon opinion sur des questions aussi essentielles que IDE n’est pas suffisamment valorisée pour pouvoir être sollicitée. Accepter que demander l’avis de quelqu'un et décider de ne pas le prendre soit pire peut être, mais dans ce cas, je m'attendrais à une solide justification de cette décision.

  • La direction, quelle que soit son expérience, ne travaille pas à 100% avec le développement de ce code spécifique. Il serait naïf de supposer que ceux qui le font n’ont pas du tout de perspicacité. Bien sûr, il se peut que les responsables aient pensé à tout ce que les développeurs proposent, mais le seul moyen de savoir est de demander.


9
Absurdité. Ce n’est pas parce que l’équipe n’a pas été consultée que les plus hauts gradés n’ont aucune idée. C'est intéressant en tant que développeur non-Java, je sais qu'Eclipse est l'EDI à utiliser assez souvent, mais je n'ai jamais entendu parler du favori des PO jusqu'à ce qu'il le poste. Ce serait une erreur de permettre à l'équipe de normaliser un IDE peu commun, ce qui créerait des problèmes pour le recrutement d'autres nouveaux développeurs.
Andy

5
Avez-vous considéré que la "haute direction" peut être constituée de développeurs expérimentés? Certaines organisations ont plusieurs couches?

2
Vous lisez beaucoup trop dans ce sujet. La direction peut avoir d'autres préoccupations, telles que les options de support, et cela peut aboutir à quelque chose qui était assez populaire avec un coût de support raisonnable (je parle des incidents de support payé). Si tel était le cas, il n’y aurait peut-être pas d’autre choix. Quel serait donc le sens de demander aux développeurs? En outre, avez-vous essayé d’obtenir un petit nombre (10-15) de développeurs d’accord sur quelque chose? Il y a une raison pour laquelle ils disent que faire en sorte que les développeurs se mettent d'accord, c'est comme garder des chats.
Andy

3
@Andy Hoarding cats is easy (parlez à n'importe quel célibataire), les entendre est un tout autre problème. ; o)
JW01

3
@ JW01 Ahh, j'ai eu le mauvais mot. Mais ne serait-ce pas un troupeau? :-)
Andy

63

Il est raisonnable que lorsque vous travaillez ensemble sur un projet commun, vous disposiez sur tous les postes de travail de tous les outils disponibles pour éditer / construire / déboguer votre logiciel, et que les principaux outils permettant de réaliser environ 90% du développement sont connus de tous. l'équipe. Cet objectif est plus difficile à atteindre si votre équipe grandit et si chacun utilise son ensemble d'outils préféré: plus de gens, plus d'opinions. Et le travail administratif devient également plus facile si vous ne laissez pas le nombre d'outils augmenter plus que nécessaire.

Bien sûr, si un développeur insiste pour utiliser son éditeur préféré, cela peut être correct tant qu'il peut s'assurer que le code source ne se présente pas ou ne se comporte pas différemment dans l'éditeur principal de l'équipe (dans votre cas, Eclipse), alors B doit éditer la source de dev A, dev B ne devrait pas être obligé d'apprendre l'éditeur favori personnel de A pour pouvoir changer la source efficacement. Mais attention, si les deux doivent travailler ensemble de temps en temps devant le même écran (ou faire de la programmation en binôme), les choses sont souvent plus faciles si l'éditeur choisi est bien connu des deux.


2
Tout d'abord, il est rare qu'un développeur doive apporter des modifications à la machine de quelqu'un d'autre. Je suis d’accord avec «plus de gens, plus d’opinions», mais ce n’est un problème que si les gens essaient d’imposer des opinions aux autres. En ce qui concerne la source, tous les projets doivent avoir un processus de construction automatique à une commande. Tant que cela fonctionne et que le code suit les conventions, peu importe les utilisateurs IDE. La plupart des IDE sont intuitifs pour des choses simples (ils ont chacun leurs avantages pour des tâches plus complexes), la programmation par paires ne pose donc pas de problème. S'il y a des questions, le développeur utilisant l'EDI peut y répondre.
Matthew Flaschen

Si vous connaissez tous les deux la langue, consulter un éditeur différent ne pose pas vraiment de problème. Certains syntaxe est mise en surbrillance différemment et le nom du fichier peut être dans un endroit différent, mais il n'y a pas de problème , sauf si vous êtes en train de l' aide de la configuration d'un autre développeur.
Izkata

30
Je travaille chez google et dans mon équipe, une personne utilise Eclipse sur une personne utilise intellij. J'utilise Emacs avec le mode Mauvais pour émuler Vim et une personne utilise Vim lui-même. Nous travaillons bien les uns avec les autres et les différences d’outils ne posent aucun problème. Il est utile d’utiliser le même système de construction et de disposer d’un guide de style pour la lecture de code, mais cela n’a guère à voir avec le choix de l’éditeur pour chaque individu.
Jeremy Wall

@ JeremyWall: comme je l'ai dit, cela peut aller si votre code source est affiché de la même manière dans tous les éditeurs que vous utilisez et que vous ne faites pas beaucoup de programmation par paires.
Doc Brown

5
@ JeremyWall: Ce n'est pas parce que votre équipe de développeurs peut travailler de la sorte que toutes les équipes peuvent travailler de la sorte. En fait, je considérerais qu'une équipe de développeurs de Google est en dehors de la norme.
James P. Wright

25

Pour la programmation en paires, il est bon que les deux parties situées devant l'écran possèdent les mêmes compétences lors de l'utilisation du clavier. Il est également intéressant de savoir que, si votre projet a des besoins de configuration particuliers dans l'EDI, il est configuré de la même manière pour tout le monde. Obtenir un nouveau développeur est plus facile lorsque les outils sont les mêmes pour tout le monde.

Mais si vous comparez cela à simplement essayer d'être le plus efficace possible, cela ne vaut vraiment pas la peine


7
+1 pour avoir noté les avantages d'environnements de développement similaires lors de la programmation en binôme
jcmeloni

1
+1 Je ne pourrais pas être plus d'accord. Travailler avec plusieurs développeurs ayant chacun leurs propres outils et méthodes de codage préférés peut être un enfer! Par exemple, vous souhaiterez peut-être appliquer de l'espace sur les onglets, une taille d'indentation spécifique et le codage UTF-8 pour toutes vos sources. J'ai déjà dû passer par cela dans mon équipe et tout le monde devait utiliser le même IDE à la fin, exactement pour les raisons mentionnées ci-dessus. De toute façon, tout développeur sérieux n’aurait pas besoin de passer beaucoup de temps pour s’adapter à un nouvel IDE, je ne vois donc pas le mal à en faire. Cela facilite également la tâche des nouveaux membres si tout le monde utilise le même outil.
Yanick Girouard

@Yanick: Espace sur les onglets, taille d'indentation, encodage ... Tous ces types de paramètres doivent vivre dans la norme de codage, que tous les développeurs doivent respecter. Peu importe comment ils veulent s'y conformer, n'est-ce pas? Les exigences de formatage doivent être centrées sur le résultat correct, et non sur la manière de s'y rendre. Si les développeurs ont besoin de changer d'EDI pour obtenir le formatage correct, je ne les appellerais pas "développeurs sérieux", désolé d'être audacieux.
Gauthier

18

Oui, c’est un peu le signe que la direction se considère comme un meilleur juge des outils avec lesquels vous seriez plus efficace que vous ne l’êtes.


38
Cela dépend fortement des raisons pour lesquelles l'IDE devrait être identique.

3
Nous ne sommes pas sûrs de la question qui a pris la décision ou pourquoi. Le terme "sans discussion" pourrait signifier qu'ils n'incluaient pas le nouveau gars.
mhoran_psprep

3
Je n'ai pas le représentant à voter, mais je suis en désaccord avec cette perspective. Même si l'outil décerné par la direction n'était en fait pas le meilleur, ce serait mieux que de ne pas avoir de standardisation. Il est clair que les développeurs ne sont pas capables de prendre la décision concernant ce qui est "le meilleur", car, livrés à eux-mêmes, ils ont tous choisi des outils différents . Il est idiot de prétendre que différents outils fonctionnent mieux dans différents contextes, car la plupart de ces développeurs ne maîtriseront pas réellement beaucoup de toute façon.
FumbleFingers

4
"Il est clair que les développeurs ne sont pas capables de décider lequel est le" meilleur ", car abandonnés à eux-mêmes, ils ont tous choisi différents outils" Ils choisissent le meilleur outil (le plus productif) pour eux-mêmes . Tout le monde a une expérience et des habitudes de travail différentes. Ils peuvent tous avoir raison.
Matthew Flaschen

2
@Andy Thats 'n'est pas vrai, comme le montrent les désaccords de Vim contre Emacs. Et ce sont principalement des éditeurs de texte, et non des IDE complets. Cela peut prendre des années pour se mettre au diapason dans un nouvel environnement.
Izkata

14

Ce n'est pas un drapeau rouge en soi.

Parfois, la direction doit prendre des décisions . Toute question nécessitant une normalisation sur quelque chose a tendance à tomber dans cette catégorie. J'ai déjà travaillé chez un client qui avait laissé les normes dériver pendant quelques années et qui disposait de plus de 20 outils SCM différents. Ce qui a commencé comme un choix indépendant par différentes équipes de développement s'est transformé en un cauchemar logistique qui entravait gravement le partage des compétences et la collaboration sur le code au sein de l'organisation. La construction intégrée était ..... euh ..... pas très intégrée .....

De plus, il n'est ni pratique ni nécessaire de consulter tout le monde pour chaque décision . La mesure dans laquelle cela doit être fait dépend de la culture de l'organisation et de l'importance / de la complexité de la décision. Généralement, vous prenez l'une de ces options moins consultées:

  1. Prenez la décision vous-même, si vous connaissez suffisamment le pour et le contre et que ce n'est pas une décision suffisamment importante pour nécessiter une large consultation.
  2. Consultez quelques personnes clés (qui seraient probablement les développeurs principaux les plus qualifiés pour prendre la décision).
  3. Soulignez le fait que vous prenez une décision pour toutes les personnes susceptibles d'être touchées (courrier électronique, assemblée publique, réunions d'équipe). Dites ce que vous pensez que la bonne décision est, mais que vous êtes prêt à changer cela si de nouvelles preuves démontrent le contraire. Invitez les gens à se manifester individuellement s'ils ont des points de vue importants
  4. Invitez les gens à former une sous-équipe pour examiner les options et recommander une décision. Bonne option s'il s'agit véritablement d'un proche appel, vous ne connaissez pas la réponse et vous voulez que les personnes impliquées soient impliquées dans la décision.

Pour quelque chose comme l’outillage de développeur (qui est une question potentiellement litigieuse), je ferais probablement 2 suivis de 3 ou 4. c’est-à-dire qu’il y aurait certainement des personnes avec lesquelles je ne parlerais pas personnellement, mais la plupart des autres des personnes clés aurait une chance de contribuer à la prise de décision.

Pour moi, le véritable drapeau rouge serait visible si vous estimez fermement que la mauvaise décision a été prise (mauvais == cela nuit à la société plutôt qu’à votre outil préféré non choisi). Comment réagit la direction lorsque vous soulevez ce problème:

  • Une bonne direction sera à l'écoute de vos arguments, merci sincèrement pour vos commentaires et réexaminez leur position au cas où vous auriez soulevé de nouvelles idées . Ils peuvent toujours ne pas être d'accord avec vous et s'en tenir à leur décision, mais ils comprendront que vous leur en avez parlé et vous font la courtoisie de dire pourquoi ils s'en tiennent à leur décision. Ils pourraient même changer la façon dont ils prennent de telles décisions à l'avenir, et si vous faites valoir des arguments judicieux, vous pourrez être inclus dans leur liste de "personnes intelligentes à demander".
  • Une mauvaise gestion deviendra défensive, affirmant que "la décision est prise" et d'autres tactiques similaires pour éviter de faire face au fait qu'ils ont peut-être pris une mauvaise décision. Ils peuvent vous voir comme un "fauteur de troubles". La société souffre, tout comme votre confiance en la direction. C'est un vrai drapeau rouge! Sortez pendant que vous le pouvez!

6
Il y a une très grosse différence entre un ide / editor et un scm ou un système de construction. et ide / editor est destiné à un usage personnel et est généralement adapté à la personne. Le système scm ou build est utilisé globalement par tout le monde. L'une de ces choses nécessite une gestion centralisée, l'autre pas.
Jeremy Wall

2
Ma réponse visait les problèmes de gestion plutôt que la décision spécifique sur les IDE en soi. Cependant, il existe également de nombreuses bonnes raisons de standardiser un IDE (compétences, formation, coûts de licence, efficacité de la programmation en binôme, intégration à d'autres outils, qualité globale de l'EDI, coûts de support, facilité de déploiement). Dans certains contextes, la bonne décision sera de standardiser - vous avez tort si vous pensez que cela peut toujours être laissé au choix individuel (même si c'est la bonne décision dans de nombreuses situations)
mikera

2
@ Jeremy: Je pense que votre point de vue est parfaitement adapté à un groupe composé d'un seul homme ou à un petit groupe de pirates informatiques. Je sympathise fortement: je suis exactement pareil pour mes projets personnels. Mais cette approche ne s'adapte tout simplement pas aux contextes de grande entreprise. Avoir une préférence pour les outils c'est bien, mais je m'attends à ce qu'un bon développeur professionnel soit désireux et capable d'apprendre et d'adopter les outils qui rendent toute l'organisation plus efficace.
Mikera

3
Mon point de vue est partagé par mon employeur Google, qui se qualifie certainement comme un contexte d'entreprise plus vaste. Je conviens qu'un bon développeur professionnel doit être disposé à apprendre et à adopter des outils pour rendre l'organisation plus efficace dans son ensemble. Je suis en désaccord avec le fait qu'une idée ou un éditeur puisse tomber dans cette catégorie.
Jeremy Wall

2
Cool, bonne entreprise et vous êtes chanceux de travailler dans un endroit capable de fonctionner en tant que "petits groupes de pirates" sur des projets relativement indépendants. La plupart des grandes entreprises n'ont malheureusement pas ce luxe. Pensez à une grande banque qui a besoin d’embaucher et de former 100 codeurs Java d’entrée de gamme en Inde pour gérer les applications de centre d’appel. Les encourager tous à faire preuve de créativité et à choisir leur propre flux de travail IDE / build ne fonctionnera tout simplement pas.
Mikera

12

Si vous utilisez maven ou quelque chose de similaire, peu importe l'EDI que vous utilisez. Il peut y avoir des cas où l'un est lié à un IDE spécifique comme eclipse, s'il existe des plugins sur lesquels vous comptez.

Je pense que vous devriez pouvoir choisir votre propre IDE, celui dans lequel vous êtes le plus productif. Cependant, comme je l’ai déjà dit, il est parfois judicieux d’utiliser un IDE standard.


par exemple. Si vous souhaitez utiliser l'ADF, alors JDeveloper est le choix naturel; les plugins d'autres ides peuvent ne pas avoir toutes les fonctionnalités.
Rohit Banga

11

J'aurais l'IDE "mandaté par l'entreprise" installé, mais je ferais quand même l'essentiel de mon travail dans l'IDE que je voulais - ce n'est pas comme si tout le monde pouvait dire quel IDE était utilisé pour éditer un fichier source.

Sur le plan IDE vs éditeur ... pour presque toutes les langues, je préfère fortement un IDE (IntelliJ) car il peut faire beaucoup plus pour vous qu'un éditeur ne le peut. Il y a des choses pour lesquelles je retourne à ST2 ou à Emacs, mais pour le codage quotidien, malgré le fait que j'aime les deux ST2 / Emacs, l'IDE gagne presque toujours.


1
Je conteste votre affirmation selon laquelle un IDE peut faire beaucoup plus qu'un éditeur. Il existe clairement des éditeurs inférieurs, par exemple, vous ne feriez pas de développement sérieux avec nano ou gedit, mais je peux coder plus rapidement dans vim que moi, et je suppose que la plupart des autres peuvent le faire dans un IDE. Et bien que je déteste défendre emacs, je suis sûr qu’un utilisateur expérimenté d’emacs est plus rapide dans emacs qu’un IDE également.
Kevin

1
@ Kevin Dispute away - Je suis un utilisateur de longue date d' Emacs et je m'améliore avec ST2. Il n'y a tout simplement aucune comparaison possible. Une meilleure finition plus sensible au contexte, une intégration de débogage plus étroite, il n’ya pas trop de choses pour lesquelles je donnerais le feu vert à un éditeur de texte. Certaines langues ont de meilleurs résultats que d'autres, par exemple, je ne coderais pas assez Java dans Emacs, quoi qu'il en soit, pour Ruby et Python, je suis à peu près moitié-moitié, mais IntelliJ me gagne. Pour l' édition de texte , que ce soit du code ou non, j'utilise un éditeur.
Dave Newton

1
Je sais que la question et la plupart des réponses sont orientées vers le monde Java, mais ici, dans le monde .NET de Microsoft, l'idée qu'un éditeur puisse être meilleur que l'IDE traditionnel (Visual Studio) est absolument en retard. Je ne voudrais pas embaucher un développeur .NET qui a insisté pour utiliser Notepad ++ par rapport à Visual Studio.
Graham

11

Chaque équipe dans laquelle j'ai été formé a eu une multiplicité d'IDE et de rédacteurs: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - cela n'a jamais été un problème. Jamais.

Pour moi, cela témoigne d'un malentendu aux niveaux supérieurs de l'organisation quant à ce qui compte vraiment. Ce qui compte, c'est de laisser les bons codeurs faire ce dont ils ont besoin et d'utiliser les outils qui les rendent plus à l'aise. L'uniformité des IDE a très peu à voir avec la communication réelle qui a lieu sur les questions essentielles de l'architecture des objets, des tests unitaires, des algorithmes, etc.

Avoir le même IDE que le prochain type signifie simplement que nous savons tous les deux comment parcourir le code avec les mêmes raccourcis et comment notre compilation / configuration est configurée. Rien de ce qui importera quand on parle de vrais problèmes de code.

Regardez, c'est habitable, en fonction d'autres facteurs de l'entreprise. Vous pouvez toujours utiliser votre propre éditeur préféré pour les tâches quotidiennes. Et peut-être que votre groupe fait d’autres choses formidables qui créent une culture remarquable. Mais les IDE mandatés sont un énorme faux pas, OMI. Pour moi, si j'interviewaient avec une compagnie et ils m'a informé que je IDE autorisé à utiliser, je les remercier poliment pour leur temps.


8

Dans notre atelier Ruby, il est fortement recommandé d’utiliser l’EDI (RubyMine) qui plait à la plupart des membres de l’équipe, car nous savons que cela fait le travail et que nous pouvons nous apprendre des raccourcis, etc.

Les développeurs sont libres d’utiliser un IDE différent, mais nous leur demandons d’avoir de solides compétences dans cet éditeur s’ils le souhaitent. Si nous voyons quelqu'un qui a du mal à naviguer dans son projet ou à éditer du texte dans son FooEdit personnalisé, RubyMine l'est pour eux.


4

Si un programmeur est un expert dans un IDE donné, il devrait l’utiliser. S'ils ne sont pas experts dans un IDE, il y en a probablement un ou deux qui sont très courants pour votre langage de programmation ou au sein de votre équipe, et il est probablement logique qu'ils l'apprennent.

Être obligé de standardiser sur un IDE semble une idée terrible.


2

Les raisons pour lesquelles une entreprise doit forcer un éditeur particulier ou un logiciel en général sur ses développeurs doivent être examinées. La partie paranoïaque (peut-être pas le mot que je cherche) pense que le suivi de la productivité pourrait s’ajouter à l’éclipse qu’ils demandent aux développeurs d’installer. Une pensée beaucoup moins paranoïaque (encore) serait qu’ils ont passé du temps à ajouter à cet IDE des outils de génération de produit qui faciliteraient beaucoup les choses si tout le monde appuyait sur le même bouton pour tester et construire leur branche de code.

Quoi qu’il en soit, ce que je veux dire, c’est que c’est probablement plus qu’une simple bureaucratie, ou une méthode pour déconner avec les développeurs.


2

C'est un drapeau rouge massif. Chaque entreprise a quelques idées stupides, mais si d’autres drapeaux rouges continuent de venir, quittez-les.


Être en désaccord. Beaucoup de grandes entreprises prennent des décisions rapidement et si elles commettent une erreur, écoutez les commentaires et les itérer. Ils ne perdent pas de temps à s’embourber dans des consultations sans fin pour chaque décision.
mikera

2

Il est facile de perdre la motivation qui sous-tend certaines décisions - en particulier avec une équipe en croissance rapide. La motivation pour passer à Eclipse pourrait bien être simplement due au fait que la plupart des développeurs semblent perdre beaucoup de temps à la simple configuration de l'EDI et que l'expertise de votre entreprise est limitée.

Je voudrais simplement prendre l’ordre de passer à Eclipse comme signifiant que vous devriez avoir la configuration d’Eclipse au cas où vous en auriez besoin, mais continuez votre travail dans votre éditeur favori. (Vous devrez peut-être passer progressivement à Eclipse si votre société commence à déployer des outils intéressants dans Eclipse.)

Drapeau rouge: J'attendrais s'il y a quelques commandes de plus irrationnelles avant de m'inquiéter.


1

Une start-up essaie généralement de rester agile assez longtemps pour élaborer un modèle d'entreprise durable. Une fois que l’argent est compris, la direction intervient pour développer l’entreprise. C’est généralement à ce moment que tous les premiers employés du secteur de la technologie commencent à partir, alors que les processus techniques se resserrent.

Comme vous le savez, vous ne savez pas ce que le code fera réellement jusqu'à ce que vous l'exécutiez. Turing l'a prouvé à ses débuts en informatique. Cela signifie qu’il n’existe pas de mesure significative de la productivité en matière d’écriture de logiciels. Cependant, pour que la direction puisse faire son travail, la productivité doit être lisible. Puisque vous ne pouvez pas mesurer le code (et que les gens ont essayé - des lignes de code, par exemple), ils mesureront ce qu'ils peuvent voir. Les programmeurs sont plus lisibles que les logiciels qu'ils développent. L’équipe de gestion type essaie de contrôler les programmeurs afin de leur rendre ces informations lisibles (au lieu de faire leur vrai travail: se mettre à l’écart). Et comme ils mesurent les mauvaises choses, cela ne fonctionne pas très bien.

Cela dit, vous pouvez toujours aller très loin avec une équipe faiblement couplée. L'équipe de développement de Github compte environ 50 personnes et enfreint chaque règle des manuels de gestion d'entreprise. Ils semblent bien se porter. Les bugs sont corrigés (éventuellement). Les fonctionnalités sont ajoutées. Les incendies sont éteints.

Ce qui est un gros drapeau rouge, c’est qu’ils essaient d’agrandir les choses sans savoir comment gagner de l’argent. À ce stade, vous devez vous demander quelle est la valeur de vos options et de vos subventions non acquises.


Cela semble totalement indépendant de la question. Voulez-vous dire poster ailleurs?
Daenyth

@ Daenyth je veux dire ceci ici. Le titre original "Un IDE pour les gouverner tous?" n'a rien à voir avec le paragraphe explicatif. Le PO semble demander si être forcé d'utiliser un IDE indique qu'il est temps de renflouer l'entreprise.
Ho-Sheng Hsiao

1

C'est sûrement une mauvaise idée. Il est inévitable que l'équipe devienne moins productive car elle doit apprendre à utiliser de nouveaux outils. Et même dans ce cas, ils ne seront pas aussi efficaces qu'avec les outils déjà utilisés .

Depuis que j'ai moi-même essayé divers outils, j'ai toujours eu à un moment donné le sentiment que "ça alors, cet éditeur me gêne avec <insérez un bogue / une différence parmi les outils préférés>". Ce sera donc un inconvénient moral.

Mais bien sûr, il y a aussi des pros pour que toute une équipe utilise les mêmes outils. Partage des configurations, skripts, plugins et tout ce genre de choses. Ce qui ne serait pas possible avec une diversité d'outils.

D'un autre côté ... ce dernier élément ne serait pas nécessaire si tout le monde utilisait son logiciel préféré. ;)


0

Vous pouvez "utiliser" Eclipse tout en continuant à taper dans SublimeText2.

Cela signifie qu’Eclipse doit être installé et configuré pour vos projets et s’y familiariser pour que vous puissiez l’utiliser aussi facilement si, par exemple, la programmation par paires. Personne (ou du moins ne devrait) se soucier de l’éditeur que vous utilisiez pour taper un morceau de code que vous avez engagé tant que le maintien de votre configuration parallèle ne prend pas trop de temps et que vous ne vous coupez pas les environnement de développement standard.


0

Si vous utilisez Git et que votre branche est en panne, vous ne devriez de toute façon pas utiliser les éditeurs des autres. Vous pouvez simplement pousser une branche et demander à un autre développeur de la tirer pour la faire fonctionner s'il ne peut vraiment pas comprendre votre ensemble d'outils. Forcer tout le monde à utiliser le même éditeur ressemble à une commande émanant d'un chef d'entreprise qui veut paraître intelligent mais ne comprend pas vraiment la façon dont vous opérez.


0

Si vous pensez à cela du point de vue de la direction, la raison pour laquelle ils peuvent le faire est pour la conformité légale. Il incombe à la société de veiller à ce que chaque outil utilisé soit utilisé légalement et ne gêne pas le produit en cours de développement. (Certains éditeurs sont gratuits pour un usage personnel, mais pas à d'autres fins, etc.) L'audit de chaque outil que chaque développeur peut utiliser peut coûter cher. J'ai vu que sur des projets où les délais sont serrés, la direction sera prudente quant aux outils / bibliothèques / etc. utilisés pour minimiser les modifications ultérieures du projet dirigées par les juristes.

Sur les projets de sécurité supérieure, il est également important de savoir où les IDE stockent les fichiers temporaires et quelles informations sont stockées entre les sessions.


0

Tout dépend des raisons pour lesquelles ils doivent recommander Eclipse. Si les développeurs rencontrent des difficultés pour configurer leurs environnements parce que tout le monde organise les choses différemment, il peut y avoir une raison de recommander une camisole de force. Cependant, si tout le monde était heureux et productif d'utiliser ce qu'il voulait, il n'y a aucune raison d'imposer un changement à quelque chose d'aussi profondément impliqué dans le processus de création.

Eclipse est bien plus qu'un éditeur: vous pouvez continuer à utiliser votre éditeur favori pour éditer votre code et à vous fier à Eclipse pour le contrôle de source, le débogage et tout ce que le flux de production mandaté par la société souhaite utiliser.

Une dernière chose - le processus de mise en application à ce niveau peut indiquer que la société a l'intention d'élargir l'équipe de développement et de mettre en place une certaine structure afin que les nouveaux coéquipiers puissent être productifs plus rapidement. Si vous pensez que Rails (ou Django) est un framework "basé sur l'opinion", vous vous rendrez compte que la structure facilite la compréhension des nouvelles applications.


0

Le drapeau rouge n’est pas tant qu’un seul éditeur / éditeur est imposé à tous les développeurs, mais que cette décision, et en particulier la décision concernant le choix de l’éditeur / éditeur, n’a pas été prise par tous les développeurs, et peut-être même aucun des leur!?!

Certes, il serait préférable que les développeurs parviennent à un consensus, en particulier parce qu'ils sont évidemment les mieux qualifiés pour la décision (du moins sur quel éditeur / IDE). Il peut y avoir de bonnes raisons pour se conformer et cette décision devrait peser de préférence dans les préférences de la direction, mais quel éditeur / IDE aurait dû être la décision de tous les développeurs.

Il serait facile de faire voter 12 développeurs. Certes, il y avait suffisamment de temps pour le faire! De toute façon, la conclusion aurait été pénible pour certains et elle aurait peut-être même fini par devenir Eclipse, mais il serait beaucoup plus discutable de qualifier l’exigence de "drapeau rouge".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.