Architecture is one of your greatest assets. If it’s so important, you likely would like to check it. So, how should you check your architecture?
Testing, pair programming and code reviewing are the proposed means to approach this problem. However, testing is only concerned with the functional side of a system, and thus, it is insufficient for capturing structural contracts. Pair programming and reviewing work well in the small, but they do not scale when you need to handle the millions of details entailed in modern systems.
Systems are data, and the only way to deal with large data is through tools. A common way of approaching the structure of the system is through standard checkers, such as FindBugs or Checkstyle. These are fine tools, but when they are left to only check standard idioms, the specifics of your architecture, which is where the main value resides, remain unverified.
In this talk, we show a different way: given that value is contextual, the only viable solution is via custom tools to extract the relevant information. Who should build these tools? Engineers. When should they build these tools? During development. To exemplify how this can work in practice, we show multiple cases of querying, visualizing and browsing systems to help guide coarse and fine grained decisions.
And, one more thing: your system is not just code. Configuration is part of it. The deployment infrastructure is part of it. Logs are part of it. Even the DB is part of it. It’s all data and you should be prepared to check it. Because it matters.
All examples from this talk make use of the Moose analysis platform. The goal is to show how we can approach a wide variety of situations only using a small set of tools and techniques. Thus, the promise is that the investment on learning how to craft tools does not have to be extensive and can be leveraged quickly.
Related links:
A related talk on using Moose can be seen here: