Exploring Elixir codebases with Archeometer

Legacy code is a liability, or so they say. Nevertheless legacy code is at least a part of most software projects. If you work on a system with legacy code, you better have a nice map that clearly marks where the dragons roam. On the other hand, as software developers, most of us switch between projects every once in a while and many times we arrive at humongous codebases. How to deal effectively and efficiently with so much code? The usual mantra is “read the code!”, but it’s not easy at all to quickly understand tens (or even hundreds) of thousands of lines of code.

What if we could obtain metadata that describes a software system from another perspective instead of just raw code? And better yet, what if this data was queryable? This is the goal of Archeometer: to gather different kinds of useful information about the system and make it available for your exploration.

Think of Archeometer as a device you can use to get an understanding of the overall design and quality of an Elixir based system, a lab in which you can interactively tune parameters and adjust zoom levels to get a pretty good grasp of a perhaps huge and not so pretty code base, an oracle for answering questions like: which are the core modules of the system? which are the parts of the system most difficult to understand? which are the ones I must be most careful dealing with? which parts are nice, safe and green?

Transcript

1. Exploring Elixir Codebases with Archeometer Augustín Ramos @MachinesAreUs
2. Agenda • What is Archeometer? • Motivation • Architecture • Analyzers • Usage • Report Overview • Future
3. What is Archeometer? A set of tools for the analysis of Elixir codebases, from the point of view of Architecture, Design and Quality. An equipped laboratory to conduct your own code explorations.
4. Motivation
5. In 20+ years as a software developer… • I have worked with • C, C++, Java, Python, Ruby, Groovy, .Net, PHP, Javascript, Elixir… • Have met with huge amounts of legacy code • With the mission of • Making sense of it ! • Fixing it !!! ! ! ! ! !
6. 10 Years of Elixir !!!
7. • 10 years of Elixir for me!!! (first commit on May 24th, 2013) • It’s enough time for people to write systems that… • Are huge • Are very complex • Have insufficient testing / documentation • Are abandoned by the original authors • Are LEGACY 10 Years of Elixir !!!
8. Who you gonna call?
9. Tooling • For some platforms (notably Java and .Net) there are very good tools for managing complexity since long time ago. • Not so for languages like Python, Ruby or Elixir. • Solution? • Lot’s of custom scripting to retrieve architectural information. • Lot’s of “read de code”. • It’s very time consuming. Not efficient at all.
10. Architecture
11. Analysis Components Data
 Collection Reports Code Query Language Mix Tasks Analyzers
12. Data Model
13. Code Query Language
14. Code Query Language (CQL) • Pretty much inspired on Ecto: • Schemas, Query DSL, Repo • Nested properties traversal. • No explicit joins needed!
15. CQL Examples 1/2 What are the modules most used within certain app?
16. CQL Examples 2/2 What behaviors are being using in your application and how much?
17. Analyzers
18. XRef • XRef is all about finding and diagraming relationships between modules or applications. • Supports both enumeration and component name patterns. • Supported output formats: dot, svg, png, mermaid. • It’s not a replacement for “mix xref”, more like a complement.
19. XRef $ mix arch.xref --format svg \\ --out kamaji_xref.svg \\ Kamaji Kamaji.Node \\ Kamaji.Peer Kamaji.Room
20. Treemap A treemap is a visual representation of hierarchical data, with the area of each subcomponent representing proportionally some defined metric.
21. Design Structure Matrix X X X X X X X X X X X X A B C D E F G A B C D E F G
22. DSM Triangularization X X X X X X X X X X X X A B C D E F G A B C D E F G F B D G C A E F B D G C A E X X X X X X X X X X X X
23. Usage
25. Basic Usage • Data collection $ mix arch.explore • Report generation $ mix arch.report.html
26. Report Overview
27. Future
28. Near Future • Repository history analysis " " • Livebook report (maybe) " • More algorithms for DSM analysis " " "
29. Sometime in the future… • Interactive diagram analysis " " " " " • On DSM • Dynamically create DSMs for selected modules • Collapse / expand hierarchies • On Graphs • Focus on certain parts of the graph • Identify patterns or interesting features
30. Q & A
31. Thank You! Augustín Ramos @MachinesAreUs