Share via

Code @ Scale

  • Article

As customers you may not be that interested about how we are internally organized to deliver the tools and services in Visual Studio, TFS and Visual Studio Online. However, it helps to have a little of that background to understand why individuals focus on the topics they do. So, given that I have been quiet so long, I thought I'd say a little about what I and my team are working on just now.

I've recently changed role, still in the realm of developer tools, but now leading a team focusing on tools and services to help developers understand, maintain and evolve code at scale. The team is split between the UK and India, with one of the team also based in France - we're very familiar with distributed working across timezones and geographies. Before this role, I was worked with the team that is now delivering Application Insights, so expect some occasional articles about that.

The starting point for code at scale comprises the following existing tools and services, which I've grouped under four high level areas:

  1. Understand code change at scale: CodeLens(TM) collaboration indicators and service for Team Foundation Version Control (TFVC)
  2. Understand code structure at scale: code map, debugger map, dependency graphs, reverse engineering to UML tools
  3. Validate code structure at scale: layer designer
  4. Generate code at scale: DSL tools, code generation from UML models

For the moment, our main push with (1) is to enhance the overall experience (see e.g. Mathew's blog post on the upcoming CodeLens(TM) Incoming Changes Indicator) and extend CodeLens(TM) support for other VC systems, starting with Git and TFVC in VS Online (the service only works with TFS on premise at the moment). We are also looking to add support for other languages.

On (2), we are currently focusing our efforts around code map and debugger map. For code map, we are looking at:

  • Improving the experience for filtering and hiding nodes and (especially) links, to reduce clutter and noise when working with maps at scale;
  • Making it easier to create "standard" maps, to take some of the guesswork out of creating maps that are useful for certain kinds of task including, for example: the full inheritance/implements graph for a namespace or keyed off a select set of types, the graph of all code that code be impacted by a change to an interface, the override hierarchy keyed off a method, and so on;
  • Creation of maps across code for whole systems, not just code for individual components or which can wholly be contained within a single Visual Studio solution;
  • Understanding systems comprising services, devices apps and web clients, making use of REST and dependency injection;
  • Using non-diagrammatic ways to explore and understand code structure where that is appropriate.

Debugger map is actually a code map, whose population is driven from a debugging session, whether that be live debugging or debugging through an IntelliTrace log. As such it will benefit from some of the enhancements to code map. However, we are also looking at a set of improvements which are specific to the debugging experience. In particular, we have worked with the diagnostics team to improve the experience of using code map with IntelliTrace, with the first results of that collaboration appearing in Visual Studio 2013 Update 2 CTP2.

On (3), we get consistent feedback from customers about the value proposition behind the layer designer, but are also aware of some the limitations of the current tool. To that end, our focus will be on converging the layer designer and code map experience, enabling layer validation at scale - beyond the bounds of a single VS solution, and enabling a richer set of architecture validation rules to be defined.

We are currently considering how best to take (4) forward.

As always we can't announce timings and plans are always likely to change, especially as we learn more via telemetry from how customers are using the product, and through informal feedback from customers about the tools and problems that are most important to them. To that end, if you have feedback/questions about your usage of the tools, or about any of the ideas described above, please get in contact, e.g. via a comment on this blog.

Comments

  • Anonymous
    March 03, 2014
    These would be way more useful if they were available in something other than Ultimate level of Visual Studio.

  • Anonymous
    March 04, 2014
    Regarding 4: Decent tool support in VS for T4 could be one way forward. For me T4 is a great tool but partly because of the lack of tooling in VS it takes a long time to sell it to other devs.