.NET Tools. Interview with Sergey Shkredov (JetBrains), Pavel Avsenin and Alexander Zakharov (DevExpress)

Some developers program with a look . Others are blind and program by ear / touch. Individual comrades enough marker and blackboard. Still, most .NET developers use Visual Studio for coding and debugging, a couple of profilers, a decompiler, a plugin for VCS, browser tools, R # \ CodeRush, a tool for controlling the database, a bug tracker, a build system and a coffee machine .

I was able to talk to the developers of some of the listed development tools.

Under the cut - a boring and completely uninteresting advertisement, a little Roslyn, a little bit of a Rider, a minimum of CodeRush, features C # 7.0 are described a little, perspectives of .NET are briefly reviewed and PVS-Studio is mentioned once.

JetBrains was represented by Sergey serjic Shkredov , the author of numerous features in ReSharper, an adept of system programming, the head of the .NET direction in JetBrains, and also one of the developers (and users) of Rider.

- Good day, Sergey. Let's start from the beginning, namely with the IDE. Now the .NET world is in a fever: new versions of .NET have come out, new versions of the studio, Rider has found its first users. When will the situation calm down a bit?

- Good day. Hope never to stop. We live in a world that is changing extremely fast. And, in my opinion, now in .NET there is much more order. MS develops it as a platform that serves all MS development stacks: mobile development, cloud, WinPhone, and desktop — all are interested in the development of the platform. One feels that development is being streamlined now: the influence of individual commands is decreasing, .NET is being developed as a whole.

- Each platform has its own limitations, will not the basis of .NET be common for everyone?

- Just the opposite. To integrate with .NET Standard, each platform develops its own API, extends them. I am surprised only by a lively Mono, I thought it would replace the .Net Core. On the other hand, Mono is developing with .NET Standard, which inspires some hope.

- Judging by the discussions of different IDEs on the Habré, the main characteristics of the IDE are the speed of work, the minimum memory consumption \ prots, the speed of loading projects, and a set of features. Are things more important?

- Of course. Performance is critical. IDE should load quickly, load projects, not block UI; Some three whales, three performance criteria.
But at the same time, each IDE supports a certain stack of technologies. That is, there are developers, they solve typical business problems, usually on the same technology stack. Accordingly, the main task of the IDE is to facilitate the work with this stack. For example, we in Rider are now concentrating on cross-platform mobile development and ASP.NET.

- Chose the most popular destination?

- Including. In addition to popularity, these stacks are not so strongly attached to MS. Many open source utilities tools. If to take SharePoint or Office of the developer - without VS it is almost impossible to make something. By the way, I forgot to mention Unity. The audience is rather big, but its needs are different from what we are used to seeing in the Web or mobile development. There is not much code, and the benefits of IDE are slightly less noticeable.

- Are you going to work with the game engine?

- No, only with the script. Roughly speaking, Unity consists of two parts: the graphics engine and scripts. They work with graphics in Unity Studio, scripts are written under MonoDevelop or VS. We will help to work with scripts.

- Previously R # was limited to .NET framework 3.5. Is this restriction now in force?

- No, we no longer support versions of VS less than 2010, too few users have left, and for VS 2010 we require 4.0. We will soon require 4.5. I would like to .NET 4.6.2, but not all of our users have it installed ... So, in the next few years, nothing will change.

- Tools are now increasingly floating in the clouds. Servers, monitoring systems, TFS, turned into VSTS ... Does the cloud IDE await us?

- For now, developers are better off sitting on the desktop, at least I don’t see any motivation for moving to the clouds. Unless mini IDE would be useful for quick fixes without a local checkout. Yes, build farms go to the clouds. If you often have a plug-in with build queues, it would be nice to be able to quickly add multiple machines to the build agents pool. In this case, too, must be considered. According to our calculations, it turns out cheaper to install your own servers.

- Do you have TeamCity?

- Yes, all our internal infrastructure lives on TeamCity. For OSS projects, we also use the public installation TeamCity.

- Question about Roslyn analyzers. The simplest working analyzer is written in a few hours, but the matter usually does not go beyond the simplest examples. And this is in the presence of ready-made solutions that can serve as an excellent specification. What is the problem with these analyzers?

- Writing them is simple, but what is the motivation of the authors? Analyzers are a cool toy. The same effect could have been achieved earlier with the help of the R # SDK. Perhaps the only advantage of Roslyn analyzers is good integration with the Build process and IDE, this is really great. But like us, there are big problems with the public API. The language is changing, which means that analyzers also need to be added for new language constructs.

Open Source usually contributes either a complete framework or a combination of a couple of complex frameworks to produce a complete tool. It’s hard to come up with a complex project with analyzers: in fact, the value of such a project accumulates with the number of analyzers. However, many of them are very similar. As a result, to get a serious product, you need to sift 100 almost identical features. Methodically, one by one to write boring pieces of code - where does the motivation for this come from? Plus, it is difficult to write the analyzer correctly the first time, the life cycle is rather big. That is, you write an analyzer, you release it, having received 15 requests for rare bugs. Pretty hard work.

- That is, for such things should be taken with purely financial intentions? The easiest motivation?

“I expected someone to take it.” Here, PVS-Studio came from. Saw analyzer for analyzer.

- What about analyzer performance?

- He suffers a lot. For example, to work with interfaces, you need to build an index that allows you to quickly analyze a dozen scripts, otherwise we will have a dozen recalculations. If you saw it in Open Source - someone must write such an index, and then the top ten developers will have to somehow connect to the index. Even at the expense of communication problems, it is very difficult.

- Developers are increasingly relying on their tools. In addition to knowing the language itself (and a couple of platforms), now you need to be able to work with VCS, debugger, a pair of profilers, a reflector, various tools for refactoring, a test framework (or even more than one), a project management system, development tools in the browser, and .NET language is constantly evolving. We are becoming increasingly dependent on tools and stackoverflow . Will there be a time when a programmer’s class will be determined by knowledge of utilities and plug-ins, not language and libraries?

- Yes, knowledge of languages ​​and algorithms is depreciated. Tools become more convenient, part of the work takes over. Remember the good old WinForms: you had to create an element, hook up to EventHandler, write a method for processing, change the model, get an answer, change a couple of components, validate a whole bunch. I recently wrote on Kotlin with React, and almost did not think about UI. I changed the model, gave it to redraw, and the framework itself picked up all the changes. Completely different approach. I think in the near future, programmers will require knowledge of frameworks, fashion technologies, understanding how to write scalable code, portable. And the algorithms and data structures are the past.

- Does this only concern the .NET world? I think the objections of system programmers will be very emotional.

- Developers of compilers and high-loaded solutions, of course, will remain. But now more and more people are programming just using StackOverflow and are happy with it.

- Has development become easier?

- Disappeared the need to understand how a particular framework works. More precisely, frameworks appear so quickly that you don’t have time to study them, and you have to trust their authors.

- Sergey, could you tell us about Team Tools (Hub, TeamCity, Upsourse, YouTrack)? How close is your set to the VSTS and Atlassian stack? What should we expect in the future?

- We collected the necessary components: YouTrack - bug tracker, TeamCity - CI server and Upsource for code review. In this case, it is difficult for us to compete with competitors, our products are fragmented. In the Hub product, we organized the User Managment, but the remaining integrations are the wagon.

- How will you fix it?

- While only plans, public statements will not be. But we understand that people work in teams, and we want the IDE to know more about teams. That is, you went to the studio, connected to the server - and your IDE already knows about your projects, tasks, bugs, etc.

- Rider. A year ago, you weren't going to get off the studio; in January, you announced your IDE. What can we expect from it (besides speed / convenience)? Plugins? Integration with everything and everyone? Integration with your Team Tools stack?

- We do not get off the studio yet. The main features of R # and proflators work with the studio (and shuffle with Rider). As for the Rider, they have already collected a significant user base. There are people who sit on the Rider for months without opening a studio (I am among them). Now we are sending links to fresh builds to our earliest private EAP users, but we are going to open a public EAP the other day, which means that Rider can be downloaded to everyone directly from the site. For us, this is an important step, the number of users has increased by an order of magnitude. We are now making a lot of efforts to achieve stability, so that the build / debug works for any projects and survives on any systems.

Separating code processing and UI, we got a pretty quick, responsive IDE. Over extensibility also worked, plug-ins can be written to the front-end, and back-end. Now we are cutting an analyzer that allows us to determine the compatibility of plug-ins.

- What is the build system used for the build?

- MsBuild on Widows, you can use XBuild on Mac and Linux (we do not recommend it, but at the same time we understand that not everyone has switched to cross-platform MsBuild). In terms of the build system, we are not going anywhere from MS.

- That is, there will be no build errors when migrating from the studio?

- Exactly. By and large, there is no migration, you open the same studio .sln and continue to work.

- You planned to release a release in the fall. Will it work out?

- Alas. We are planning release for the beginning of the next year. The product will be paid, and we do not want to be ashamed of what we take the money for.

Another manufacturer, DevExpress, was advertised by adepts of pair programming:

Pavel pavsenin Avsenin
.NET-developer, in the era of the boom Flash escaped into developing applications for social networks. Four years ago, he came back and since then helps to choose beautiful names for new variables in the CodeRush team. Great lover to contemplate different header files, especially in spring.

Alexander alexandrz Zakharov
Inspired by computers and programming in early childhood. Passed through ZX Spectrum, BASIC, Pascal, C, C ++, Java, and eventually settled on C # and .NET.
Now he is developing CodeRush in the company DevExpress.

- Good day. Now the .NET world is reeling: there are new versions of .NET, new versions of the studio. In DevExpress, almost all products are tied to at least one of these components, how hard is it for you to keep up with MS?

- Yes, MS is developing .Net Core, Xamarin, launches Standard, and we are happy about it. Technology develops - it means it lives. As for support, we have our own approach: we monitor any technology from the very beginning of its existence, but we seriously start working with it only after some stabilization. We look, we try, we make builds, but we don’t post it publicly. So, we watched .NET Core and didn’t take active steps until the release. So, all the changes compared to the RC did not affect us. In addition to the fact that we are not wasting our time on supporting “not fired” products, requests from customers accumulate over the waiting period, which allows us to prioritize more accurately.

Although failures happen with us. For example, we spent a lot of resources on supporting stillborn Silverlight.

Recently it has become easier to work: a lot of things are in OpenSource, there is Early Access. It became easier to respond to changes, we learn about them earlier.

- Sometimes competitors create something up to you. How much do their products help you?

- We do not have priority in speed, our goal is quality. We look at the decisions of competitors, we take into account their successes and mistakes, but we try to build our strategy based on the requests of users and their feedback.

- Question about Roslyn analyzers. The simplest working analyzer is written in 5–10 evenings, but the matter usually does not go beyond the simplest examples. And this is in the presence of ready-made solutions that can serve as an excellent specification. What is the problem with these analyzers?

- Firstly, there are similar analyzers (one hundred pieces in a package).

Secondly, the API is smart, but the approach of immutable trees is unusual for most developers.

Thirdly, one analyzer is really written in a few hours, but usually people need a whole range of such things, for which a command is already desirable, preferably writing a product for money (this significantly speeds up the project).

Why hasn't such a team appeared in OpenSource yet?

- MS itself develops its refactorings. I guess no one wants to compete with them. Plus, there is a question of motivation: a really big and complex project needs to be supported, and it’s risky to rely on support in OpenSource. So it turns out: nobody needs a small project because of a lack of functionality, a big one because of possible risks with support.

“When we write an analyzer, we throw a place to the fixer, and it runs around the code a second time.” How do you solve the problem of re-computing?

- If you run on the syntax - you have no problems, it is fast. If semantics are processed, Roslyn has its own cache. In general, the problem is small. And then, to talk about repeated calculations in a vacuum is meaningless. Most often it is necessary to measure each analyzer separately.

- DevExpress was mentioned as a contributor to Roslyn. How open is the project, how is it developing, what are the trends now in its development?

- Specifically, the CodeRush team did not contribute. We had one idea, but it was already seriously sawed, so we decided not to interfere.

As for openness: everyone can join the great, the project is developing actively.

Each studio update is a performance upgrade, sometimes an API is opened. So, in the 3 previews, the export of the content providers was allowed to insert autocompletions into the IntelliSense main session. There was an API internal, it became public. Now also C # itself is actively sawing up to version 7 (it would be faster already), features are added, including from functional programming. Well, and routine: fixes, performance, polishing API.

- Announced .NET standard 2.0. Will it become a single standard, or can you download a picture about 15 already 16 standards?

- Taki will. .NET Core, Desktop, Xamarin - everything will be there. Everything depends only on MS, they have a desire, Roadmap is there, so they will complete their work. On the other hand, as seen from the experience of previous attempts, the unification process is complicated and thorny, there are many platforms. Most likely, you will have to make several attempts.

For sure there will be difficulties. Once the API is common and the implementation is different, undocumented features will appear, once they appear, they will be used, once they will be used, the code will become intolerable. And even though it will be a developer’s jamb, an intolerance will appear. Performance under different platforms will vary. There may be some exception or attribute NotSupportedPlatform.

In other words, the unification will end, but when exactly - only time will tell.

- What standard MS will stop? 4.5, 4.5, 4.5.1?

- They will work forever. Not only because it is profitable for them to work on something, but also because the world is changing, new opportunities are opening up. And there are new competitors.

Now MS is engaged in IoT, perhaps .NET will appear for coffee makers. Maybe they will .NET for browsers, TypeScript hints. Developments in native compilation are underway. Opportunities - a million.

- Now the marketing wave of messenger bots has begun. Are there Skype assistants for admins / testers / developers?

- There are already similar things. For example, the bot connects to the build server, it looks at the latest builds, if there are red ones - it sends a message to Slack. On the other hand, bots are just an interface. If there is any software for the task - it can be screwed to the bot. Unless there is some difficulty with processing commands in the messenger, you may need intelligent utilities.

- DevExpress has a solid set of tools, and it is very different in “direction”: addition to IDE, graphics, test framework, analytics tools ... At the same time, they seem quite heterogeneous. How hard is it to maintain such diversity?

- The main direction: the development of components for different platforms. Graphics. Components, controls for WPF, WinForms, JS, etc. The rest is just some kind of development of the idea of ​​components. There is diversity, but usually there is a system and its supporting team. So the main problems arise in cross-project communications.

- CodeRush supports all popular test frameworks. How do you resist the temptation to write your own?

- The fight against temptation is simple - we have no temptation. There was a thought to make a mock framework with the ability to replace the non-public API and the behavior of types from BCL, the thought is still there, but the priorities are different. There is nUnit, xUnit - there is no need to butt with them, they do their job well. In addition, we had requests for a continuous test run (in the background), but these requests are few.

- What tools are popular in the office developing tools?

- CodeRush. Although some people do not see the benefit of such a toolkit, they do not use it in principle. VS. nUnit, xUnit. Git, Mercurial. Your own bugtracker, Trello as a scheduler, proflators from PerView to dotTrace. Its solution for CI, based on CruiseControl. Overall, the zoo is extensive.

- Developers are increasingly relying on their tools. Will there be a time when a programmer’s class will be determined by knowledge of utilities and plug-ins, not language and libraries?

- Tools save time, and a lot. Is it possible to call yourself a programmer without knowing how to use them?

Again, maybe somewhere else an anachronism has been preserved with the division into designers, programmers and testers, when the designer designs the architecture, gives it to the mob, which programs and then gives the code to the other mob, which tests. Our developer does all these things by himself, and the requirements for the developer are relevant.

- At the interview you ask him about your favorite tools? Is this a critical question?

- Not critical. If a person does not know something: perhaps he did not use it, there was no reason. Learning is important. It defines the class of the programmer.

- Honestly, I have not come across functional languages ​​yet. About update. NET news flash often, and F # is almost not mentioned. Is the language still evolving?

- There are few mentions for one simple reason: everything that is already on board. Since version F # 3.0, there are only minor cosmetic improvements. Recently, MS is trying to integrate with Roslyn at the level of the project model (Workspace API). By the way, interest in F # is only growing. Conferences, videos, posts appear. There is a small but dedicated community.

Although the scale, of course, is incomparable with C # (for now). If to compare quantities - on one F # of developer it is necessary ten developers C #. Just because of the functional paradigm, not everyone is comfortable or clear. Most likely, over time, F # will catch up with C #, or merge into it. This is not a language for finance, Machine Learning, it is a great language for everything.

- Will CodeRush appear for F #?

- Now it’s poor, there is Visual F # Power Tools - and that’s it. The rest is point tools. Regarding CodeRush for F # - it all depends on the requests of our users. They exist, but there are not many of them yet. Perhaps, after integration with RoslynWorkspaceApi, the task will become easier, and we will think about it seriously.

- How realistic is it to use CodeRush for training? It highlights errors, offers corrections.

- Fixing - possible. Nakosyachil - immediately got stuck. Polite. As for learning, no. Some juna see a mistake - googling. What, why, why it is impossible, why it is necessary otherwise. The rest, without thinking, apply refactoring. Moreover, if you rely a lot on the tool, you stop developing at one moment. Why, if clever tulza does everything for you?

- CodeRush. What is the fundamental difference from R #? Do you compete, or occupy two niches?

- These are tools of one class, tools of developer productivity, and they occupy one niche. In fact, they appeared almost simultaneously. When the first studios first appeared, MS had IntelliSense and that’s it. Then CodeRush and R # appeared.

- Almost 15 years of history?

- Yes. Although now history is being rewritten. At one time, the products were similar, they clung to the studio, they braked it. That is, the studio previously parsed the code, and CodeRush \ R # parsed it. Then, on the editor’s side, access to the compiler was required, MS made the CompilerAsService, external utilities had the opportunity to cling to the compiler ... well, two years ago we copied everything to Roslyn.

- A couple of years ago you bet on Roslyn (still raw at that time). What do you think played your bet?

- The main desired buns we received: we managed to avoid double code parsing (and this is double computation and memory). Plus, now we have become calmer to accept new features in C #, it has become easier to handle them. You do not need to fix your own code parsing algorithms yourself; a parser and resolver are automatically obtained. Almost all the “routine” is done, it remains only to write new features. It's hard to talk about winning, we think, time will tell.

We compared the CodeRush versions (with and without Roslyn) - the Roslyn version takes a bit more RAM, but this is not critical. That is, Roslyn really eats a lot of memory, but when processing syntactic and semantic trees we use only its resources, now CodeRush itself does not add anything. When we started the transition, the immunity tree raised many questions. It was assumed that the managed compiler would be inhibited. But it turned out that trees can be processed in several threads, which speeds up calculations. As for the “raw” Roslyn - at that time the project was already several years old, his team of excellent specialists wrote, and it was clear that MS was improving it. “Stranger” - maybe, but it is fixable. And yes, when we seriously undertook the redevelopment of CodeRush, the studio was already spinning on Roslyn and was quite stable.

- What about the idea of ​​separating UI and compiler (as in Rider)?

- JB has a platform for writing IDE. Popular, one of the best. There are relevant specialists. We have no such conditions, so we have not seriously considered this option. In our opinion, .NET and MS are inseparable. Maintaining your compiler is a laborious task, and we decided to follow MS.

If you have read these interviews and not enough for you - come to DotNext 2016 Moscow . At the conference, we will talk not only about tools: let's take a look at both performance and multithreading and much more:

⬝ .NET Core: State of the art
⬝ Squeezing the Hardware to Make Performance Juice
⬝ Intellectual chatbots and cognitive services
⬝ Stack Overflow - It's all about performance!
⬝ Advanced Xamarin.Forms
⬝ C ++ via C #
⬝ We continue to talk about arithmetic
⬝ ASP.NET SignalR: Cruise for Web Development
⬝ Exceptional Exceptions in .NET
⬝ .NET code modification in runtime
⬝ End-to-end JIT
⬝ Performance tuning Stack Overflow tags
# C # Scripting - you can have thought of before!
⬝ Multithreading Deep Dive
⬝ Collect All, or Meet Cake (C # Make)
⬝ WinDbg Superpowers for .NET Developers
⬝ Overview of the new .NET Core and .NET Platform Standard
⬝ What vulnerabilities are found in the .NET platform and how not to repeat them in their applications
⬝ What's new in C # 7?
⬝ ETW - Monitor Anything, Anytime, Anywhere