Frameworks for Coding Confidence

Frameworks for Coding Confidence

As a mobile codebase grows and evolves, it becomes increasingly difficult to make large changes with confidence and speed. Unintended side effects, strange lifecycles, memory leaks, error-cases, and poor code cohesion work together to quickly make a mess of many applications as they grow. This talk will cover some of the techniques Uber has used to allow for changes in a tightly integrated application with confidence, including tools like Dagger 2, static analysis, and annotation processing. We’ll show you how these techniques and tools reinforce each other by demonstrating some concrete anti-patterns that have scaled poorly in the past, as well as how you can combine these new techniques to prevent entire classes of issues in the future.

2a87e37389533dab1ddea0c508868d5a?s=128

Luke St.Clair

March 20, 2016
Tweet

Transcript

  1. Frameworks for Coding Confidence Luke St.Clair, Engineering Manager March 18,

    2016
  2. • How do you make big changes? • What did

    Uber do? • What worked? • Key point: How do these frameworks and tools work together? Rapid Change A good problem to have
  3. None
  4. What helps you move fast? Code grows fast Safety/Confidence This

    should be controversial, but consider where development time goes. Compilers Make the compiler do as much for you as possible, then the linter, then testing.
  5. • Very key way to express developer intent. • Where

    do you pass around an integer? • Basis of many other mechanisms for safety. Annotations Much @. So Java.
  6. None
  7. Validation Natural consequence of annotation More than just IDE hint

    You did the work to tell Java what your code does - why isn’t it helping more? Enforcement What does any of this do? Is it just for the IDE?
  8. RAVE Runtime Annotation Validation Engine Enforces Annotations At runtime, you

    can tell if the state of the program is the state your annotations describe. Enforcement Annotations express intent, annotation processors can help you verify this intent.
  9. Validation (continued) Natural consequence of annotation Can go further First

    step is to boil this down to arbitrary conditions. Can be complicated Most apps have implicit dependencies and data relationships (imperfect APIs).
  10. Integration

  11. Infer is a static analysis tool from Facebook that detects

    a pretty wide variety of bugs, from resource/context leaks, to some security violations. The most common use case, however, is for null pointer exceptions. Static Analysis Brought to you by Infer
  12. http://fbinfer.com/docs/eradicate- warnings.html Yeah, this one is obvious. Null Field Access

    Brought to you by Infer
  13. If a subclass or interface implementation doesn’t return the correct

    nullability, Infer will complain. Subclasses don’t annotate correctly
  14. If you forget to annotate a parameter or a return

    value, Infer will catch this. Infer catches missed annotations Brought to you by Infer
  15. Some engineering is required to use Infer. • Homebrew •

    Gradle • Build times - Caching Infer in Practice
  16. This is sample output from an Infer run. • Multiple

    types of issues. • Automatically analyzes every diff Sample Example Infer Run
  17. • Scopes - high-concept • Dependency resolution - It becomes

    harder to introduce a weird relationship • Helps prevent things like weird circular dependencies • Touch points to help you think about what you’re exposing • If it compiles, it runs. Dagger 2 Compile time scoping and safety
  18. • Easy to add another dependency • Hard to mess

    up the scoping • Can’t mess up the dependency relationship - Well, mostly • There are not many tools to help with lifecycles. Dagger 2 Compile time scoping and safety
  19. • You pay the price for Dagger 2 • Verbosity

    • Testing Dagger 2 Not all easy
  20. Other tools There is so much here Lint Checkstyle Extension

    points help guide consistency in the code base, and make it easy to ensure new code doesn’t accidentally skip some of these important checks. Gradle If you haven’t looked at all possible lint rules, do so. Custom lint is extremely powerful. There’s nothing like a 2 vs 4 space flamewar to slow you down.
  21. How do these combine? Better together Rave Infer Dagger Fills

    in the gaps, helps ensure Android-isms are enforced across libraries. Lint Establishes a baseline set of constraints that you know is satisfied in production. Because RAVE tells you the starting point for data, you know that it will continue to be enforced throughout the lifecycle of the application. Generated objects in DI don’t break the analysis chain. Dagger 1 >> Dagger 2.
  22. • @Inject supported • @Bind even supported • Establishes constraints

    even in the lifecycle of injection. Dagger + Infer
  23. • Remember the infer modes from a few slides ago?

    • Catch missing annotations • Those are now enforced with RAVE when they terminate in parts of your mobile app. Infer + RAVE
  24. Let’s say we find a new way to prevent a

    systematic problem. • Remember String.format? • Custom grade plugins apply this over all our code. • Can apply across many teams. • If it doesn’t get applied widely, it doesn’t matter. Tying it all together Gradle to the rescue
  25. Lots of fragments here, and other Droidcon talks. Hope to

    have more to share soon. View Based Development Easy to understand, lifecycle is complicated, fast testing. Stick with POJOs By paying attention to testing at the start, we make it much easier to separate and isolate code. Testability And more…
  26. Luke St.Clair Android Platform, Uber lukesc@uber.com Thank you