In the beginning of the personal computer revolution, circa 1975, the IDE was invented. It was called Maestro I and it was the first “modern” development environment. The Integrated aspect of the IDE refers to the combination of a source code editor, build automation tools and a debugger. Since then, a plethora of IDEs have been developed ranging from VI and VIM to Emacs, Visual Studio, Sublime and VS Code. The term has evolved to refer both to the source code editor as a standalone tool, as well as the more complex environments that integrate multiple tools.
A more modern concept of integration refers to the ability of an application to connect to another, typically developed by another entity or company. For instance, the Jira Integrations page displays a collection of hundreds of third party applications not produced by Atlassian that connect through APIs to Jira. Let’s explore now the state of the IDE world.
SEE ALSO: COVID-19: Developers Must Choose Collaboration in an All-Remote world (Part 2)
The modern Connected IDE is taking over
Much has changed in the last 5 years in the IDE world. When Stack Overflow asked developers to select their favorite editor/IDE in 2015, these were the results (Note that you can vote for more than one editor, so totals can add up to more than 100%):
Sublime and NotePad++ were leading the pack, while Atom, a product of GitHub, was just emerging as the first truly extensible editor. Atom was built on Electron, and was touted as A hackable text editor for the 21st Century.
In 2017 the state of the IDE had already changed significantly:
While the question itself had changed (now segmenting web/desktop/sysadmin), the top dog was now Visual Studio for both Web and Desktop development, while Atom moved up to 20% and IntelliJ to 23%. Visual Studio and IntelliJ charged for their editor, while Atom was free to use and Open Source.
By 2019, the picture had changed again, now with a new leader from Microsoft:
Visual Studio Code, an Electron-based Open Source free editor is now the #1 IDE in the world, and it’s very extensible. Atom has fallen off and will probably continue its decline in 2020, now that GitHub (publisher of Atom) is also owned by Microsoft. All modern editors now support plug-ins, and therein lies the collaboration opportunity: The connected IDE.
From the Personal IDE to the Connected IDE
Most developers today continue to code in a Personal IDE mode. When it’s time to ask a question or have someone review their code, they move it over to a different environment, outside their IDE, losing context and unnecessarily introducing friction. This is a big deal because quality and productivity suffer. At CodeStream, we have interviewed over 2,000 development teams to find out how they go about producing code. Let’s take a look at two scenarios that benefit drastically from having a connected IDE.
Asking a question:
- Personal IDE: Before we all began working remotely, a tap on the shoulder was probably the most common way to ask a question. Now, if a developer has a question, she will copy and paste the code in question into Slack or MS Teams (or even take a picture of their screen!), explain the context (repo, file, line number, etc.), find the right person or channel to ask, and when she gets the answer, that interaction will soon scroll off the screen in an ephemeral chat stream that will not contribute to sharing knowledge within the team.
- Connected IDE: She can just select the code in question, comment on it (like you do in Google Docs), select who to share it with (the context is self-evident here, so no explanation needed), get the answer, and everyone on the team can now benefit from that knowledge, like this:
SEE ALSO: Eclipse Theia 1.0 is an open source alternative to VS Code
Requesting a Code Review:
- Personal IDE: Most developers use GitHub, GitLab or Bitbucket to request a code review. That is also where the reviewer performs it. It may feel like that is the right environment for this discussion but in fact, it introduces multiple points of friction that make code reviews slower and harder. 1) It takes you out of your natural coding context by moving the discussion to a web browser, where understanding code is unnecessarily difficult. Why would you want to limit the amount of visible code to just a snippet? If you need to get more context, you need to go back to your editor. And to know what’s happening, you still need a notification tool, like email or Slack. In addition, 2) It forces the author of the code to predetermine what should be reviewed by establishing the PR as the earliest possible time for a review. What if I just want some feedback on WIP or uncommitted code?
- Connected IDE: As your IDE is already connected to your reviewers’ IDE, the steps are simpler and shorter. First, you do not have to switch context. Your IDE knows exactly what changes you have made. Some may be ready for a formal review, others just for a quick check on general direction. Your IDE can package up every change automatically, ask you if you want to remove any changes from the package and make the request for a review to your preferred reviewers, notifying them through Slack, MS Teams or email, or even easier, just seeing a badge in your IDE letting you know that a review is awaiting. The reviewers can perform the review in their connected IDE and see exactly the state of the code in the author’s editor. The reviewer can comment, suggest, and question with full context. The review can be completed even before a PR is created. Easier and faster. Like this:
In the future, every IDE will be Connected
Atlassian, one of the world’s largest development tool companies, believes that teams are the foundational unit of the company’s culture. So strong is their belief in teams that the stock ticker for the company is in fact TEAM. But culture is only the first step in enabling teams to optimize their performance. As we will see in the next post, the Connected IDE has a big role to play in fostering a positive and productive team environment.
The post The Connected IDE is the gateway to increased developer collaboration (Part 1) appeared first on JAXenter.
Source : JAXenter