Use your source code as documentation for your stakeholders

As developers, writing documentation is not our favorite activity. Keeping it up to date is even a bigger challenge. Developers claim that source code is documentation itself, but do stakeholders agree?

What if our code would be the source of our documentation, for team and stakeholders?

As a development team, writing documentation is often not our favorite activity. And keeping it up to date after every code changes is a bigger challenge. Developers claim that the source code is the documentation itself, but do your stakeholders agree, do they actually read the code? What if our source code would be the source of our documentation, for the team and our stakeholders?

In this session we will see how we can utilize Roslyn to generate documentation. Like creating diagrams that display the structure and relationships within an aggregate, or a sequence diagram that displays the flow throughout the application.

We will dive into the code to see how we can load projects and solutions, use syntax trees to walk through the structure of our source code, and detect branching logic to capture alternate paths. Then we will render this data to other file formats such as PlantUML, Markdown and AsciiDoc.

After this session you will be able to let your source code speak in forms that your team and your stakeholders explain to the operation of your application.

Facing this challenge myself, I investigated how to use Roslyn for this purpose. I want to share my findings how I use it in my development teams and projects. I share all my code for this via GitHub (https://github.com/eNeRGy164/LivingDocumentation) but this talk is not a commercial for this project.