2.2 KiB
Program Analysis
Program Analysis tools
Generally program analysis tools come in two forms, static and dynamic. Each has tradeoffs that we need to understand, especially when we start to build these tools.
It's important to understand what each analysis tool is good for, knowing what it's strong at detecting, as well as knowing what they are not good for and where they struggle.
Examples of Static Analysis
RuboCop Gofmt Rufo
Good
- Detecting syntax errors
- Detecting simple semantic errors
- Detecting style violations
- Detecting code convention violations
Bad
- Prone to false positives and false negatives
- Requires access to source code, including libraries
- Does not account for runtime environment
Examples of Dynamic Analysis
Profilers
- ruby-prof
Memory leak detection
- Valgrind
Data Races
- Go race detector
Good
- Detect bugs that only can occur at runtime
-
Capable of measuring things inlfuenced by factors outside of source code
- e.g. Network latency, External errors, etc
- Generally less false positives and false negatives because error cases must occur to be detected
Bad
- Requires actually violating edge cases to report them
- Often incurs performance penalty to instrument live code
- True positives can be missed for code paths that are not exercised often.
Problem we're actually facing
- Monolith is large and old
- OAS is used as the source of truth to generate clients and documentation that customers rely on
- Monolith and OAS don't agree most of the time
Solutions we're trying
https://github.com/equinixmetal/api-spec-inspector - form of SA
Back to basics
How do programming languages do their job?
Source code -> interpreted -> output
If you're in a compiled languages
source code -> compiled -> executable -> output
We treat "interpreters" and "compilers" as black boxes for the most part.
Let's pull back the curtains on these things though:
How does code get interpreted?
- Show ruby-parse
- Talk about AST
Utilizing the AST
ex 01-03_
Problem areas for test parsing
ex 04 vrf params