Se você não é capaz de entender uma implementação lendo código, é bom começar. Mesmo que por hobby, ler código lhe fará entender melhor como as coisas funcionam, ou pelo menos lhe dar mais opções na hora de avaliar alguma implementação. Há inúmeros projetos Open Source bem documentados, no entanto quando se depara com algo recente, a escassez de documentação é uma realidade dolorosa.

Ao encontrar um projeto relevante, provavelmente buscará um tutorial, ou algo que te aproxime do entendimento, mas nem sempre esse tipo de material está disponível. Há momentos que você quer algo específico e também não encontra conteúdo indexado no google. Há momentos em que você só quer entender como um pedaço do projeto foi feito, para entender como alguns problemas são resolvidos, quais padrões foram usados, enfim, como foi feito. Ler código é importantíssimo.

Na hora de usar uma nova biblioteca ou framework, você pode até usar a tentativa-e-erro, mas acho que posso te ajudar a ser mais assertivo, principalmente quando falamos de .NET, seja no .NET Framework, .NET Standard ou .NET Core. Então vamos aos conceitos necessários para entender o que quero propor:

IL

Os assemblies .NET são feitos de IL, intermediate language, uma linguagem agnóstica resultante da compilação de fontes .net. Seja C#, VB ou F#, seus compiladores geram IL para assim ser executado pelos runtimes, independente da tecnologia. Há exceções que não comuns no dia-a-dia, principalmente quando falamos em .NET Native. Fato é que enquanto IL, você consegue fazer engenharia reversa, e assim com algumas ferramentas simples, você pode entender esses assemblies olhando seu código.

PDB

O processo de build pode ou não gerar PDB’s de acordo com suas configurações, os PDB’s são databases de mapeamento que guiam o de-para entre fontes e IL, permitindo o debug step-by-step, mas para que isso funcione, você precisa do fonte original do projeto.

A proposta aqui é mostrar isso apenas com uma DLL ou EXE, por exemplo.

NuGetPackageExplorer

O NuGetPackageExplorer lhe permite buscar, abrir e inspecionar pacotes nuget. É um projeto simples que e fantástico, pois permite que você veja detalhes de um pacote, quais são suas distribuições e muitas vezes ajuda a entender se aquilo vai ou não ser compatível com sua aplicação, principalmente em dias de .net core.

Agora, com o pacote, você pode explorar o NuGetPackageExplorer e entender melhor o que é possível. A propósito, é excelente para entender como os pacotes nuget são criados.

De posse do pacote, no NuGetPackageExplorer, você pode escolher um assembly e simplesmente salvá-lo no disco, vou fazer isso com o exemplo do NHibernate.

Agora vamos às outras ferramentas.

ILSpy & dotPeek

As duas ferramentas tem a mesma capacidade, o ILSpy sendo open source, já o dotPeek, proprietário mas free, e fornecido pela JetBrains (a mesma do resharper). Eles são responsáveis por analisar IL e descompilar, gerando como produto, código fonte. No caso escolhi C#, o ILSpy, por exemplo é capaz de gerar código em C#, VB e mostrar a própria IL. Em compensação o dotPeek apresenta o código de forma mais clara, intuitiva, e ainda permite inicializar um symbol server, direto a partir de sua interface, algo incrível.

O ILSpy você pode baixar do site http://ilspy.net/ enquanto o dotPeek você encontra em https://www.jetbrains.com/decompiler/.

Conclusão

Com essas 3 ferramentas, que você deveria ter em sua máquina, você consegue entender melhor como as coisas são feitas, como os padrões são usados e consegue ser um programador melhor. Vale lembrar que as duas ferramentas de descompilação usam código próprio para fazer isso, já que não há um método oficial, então depende de know how de quem constrói esses produtos para fazer o parser adequado de uma IL para a linguagem escolhida.