开发者

Pair programming, mixed IDE environments?

开发者 https://www.devze.com 2023-01-06 08:53 出处:网络
Anyone got any experience of teams doing pair programming where there is a mixed IDE environment? I\'m a long time IntelliJ use开发者_运维问答r, others use Eclipse, which you may have heard of.

Anyone got any experience of teams doing pair programming where there is a mixed IDE environment? I'm a long time IntelliJ use开发者_运维问答r, others use Eclipse, which you may have heard of.

In my mind pair programming involves a lot of passing the keyboard between the programmers. But every time I get the keyboard I grind to a halt as I don't know to do anything anymore. (It's like suddenly I'm an idiot!)

Now I could, probably should, learn my way round Eclipse. (Not starting a holy war here about relative merits.) But I wonder if anyone else has got an opinion?


I don't see the need for passing the keyboard around. In my view, you work on part while the other half of your pair looks over your shoulder. Sometimes I imagine you would have to take the wheel, but generally not every 10 minutes. If he types for 4 hours, then you switch places, just switch IDEs at that time.

I agree you should learn the tools that are used, and if there is an actual published or documented standard you should follow it, but if you are allowed to use any IDE you want, then I don't see an issue. But if it inhibits your ability to deliver, then maybe you pair up with someone using the same IDE as you.


About 10 years too late for the OP, but this question is still highly ranked in search engines, so others interested in remote mixed environment pair programming can try CodeTogether. It's available for for IntelliJ, Eclipse, VS Code and IDEs based on them.

Participants join in a browser, but get a full IDE-like experience with IntelliSense, validation, reference searches, navigation, etc. CodeTogether is simple, fast, free, anonymous, and encrypted. The plugins/extensions are in the normal marketplaces/registries you'd expect and are also available on the website.

Full disclosure: I work for Genuitec, the makers of CodeTogether, and we really hope you enjoy it. Any constructive feedback on Gitter or GitHub is always appreciated.


I have not done this in a multi-IDE environment. But pairing is, to my mind, far and away the best way to learn IDE features. So you should come up to speed quickly on Eclipse, and your colleagues, likewise, should get a handle on IntelliJ in short order. Both of you will become better versed in both environments - and that's a good position from which to settle on a team IDE, should you choose to do so.

By comparison with other means of learning, pairing teaches you the features that are useful to you (or your pair, who probably has a similar set of needs). You learn almost by osmosis; as your pair uses a feature you may find yourself asking, "how did you do that?" or "what did you just do?" This is teaching you the features you need, exactly when you need them.

In your situation, there may be additional value: you may find yourself wanting a feature that your IDE offers; your pair may never have encountered it (but it might be in Eclipse, too). So you spend a minute tracking down that feature, and now both of you have learned new (and useful) functionality of the IDE.


Standardize your environment! As much as you need a common source style, I would argue you also need a common way of working, including having a common IDE. All kinds of settings, knowledge, plugins, etc. is much easier to share, including your example about pair programming.


In pair programming, the pair should standardize on an IDE.

My suggestion would be either to pair with another IntelliJ user or, if the rest of the group is on Eclipse, start learning Eclipse.

You're going to lose too much time switching between IDEs to gain the efficiencies of pair programming.


You could have both IDEs loaded on the pairing machine and switch between them as needed, but I'd recommend standardizing IDEs with your pairing partner. You might want to bring this question up in your next retrospective and see what the team consensus is.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号