Make or Break

This talk will focus on automating the tedious tasks every team has. Everyone knows you should write clean code, unit test, and check for common bugs. But sometimes, it's hard... Sometimes you forget... Well in this talk we will focus on making it easier. How to automate the process, make your build servers do most of the stuff for you, and increase visibility of your tasks and their progress to your team. I will focus on both a setup for a new project, where you start from scratch and where you will want to keep the slate clean, but also for existing projects where you will want to pay your technical debt, a bit at a time, fixing your project, but also not disrupting your daily routine.

Transcript

1. MAKE OR BREAK
   THE PROPER WAY TO CODE
   STANOJKO MARKOVIK
   

   View Slide

2. HI, I’M TANCHO
   ▸ 10 years of professional experience
   ▸ My first project on Android was in 2009
   ▸ Shipped code to millions of users

   (and survived crashes from a lot of them)
   ▸ Lead Mobile Engineer @ ContentSquare
   (We’re hiring) -> https://goo.gl/zc4yd8
   https://www.linkedin.com/in/smarkovik
   

   View Slide

3. THE L WORD
   WHAT IS LEGACY CODE
   Legacy code is not old code.
   Legacy code actually describes a code base that is no
   longer engineered but continually patched.
   Over time, an unlimited number of modifications may be
   made to a code base based on customer demand, causing
   what was originally well-written code to evolve into a
   complex monster.
   Has your code been called Legacy?!
   

   View Slide

4. TALK
   MAKE OR BREAK
   We will talk about
   ▸ How to improve your code quality through automated
   Quality Assurance tools
   ▸ We will demo you concrete examples
   ▸ The demo project is available on Github

   https://github.com/smarkovik/make-or-break
   

   View Slide

5. THE L WORD
   WHAT MAKES CODE "LEGACY"
   ‣ Lack of regular maintenance a.k.a refactoring.
   ‣ Lack of tests.
   ‣ Fixed version dependencies.
   ‣ Lack of Documentation.
   ‣ Code smell. (code in comments, dead code, huge code
   blocks in methods and enormous classes)
   ‣ Code rot. (duplication, complexity, anti patterns)
   

   View Slide

6. TOOLS OF THE TRADE
   WHERE DO WE START
   ▸ Increase project visibility
   ▸ Add GIT branch protection
   ▸ Continuous issue discovery
   

   View Slide

7. WHAT WE WANT TO ACHIEVE
   INTENDED GOAL
   ▸ Improve the build system to be more reliable
   ▸ Make the system transparently upgradable **
   ▸ Generate documentation
   ▸ Continuous code smell detector!
   ▸ Code style verification
   

   View Slide

8. TOOLS
   THE QUEST FOR THE RIGHT TOOLS
   We will be looking at how to integrate
   ▸ Lint
   ▸ Findbugs
   ▸ Infer
   ▸ Checkstyle
   ▸ Jacoco
   

   View Slide

9. TOOLS OF THE TRADE
   ANDROID LINT DEMO
   Checks :
   ‣ Java
   ‣ Resources
   ‣ Manifest and XML configs
   Approach taken :
   * Enable all
   * Warning = Error
   

   View Slide

10. TOOLS OF THE TRADE
    FINDBUGS DEMO
    Findbugs - Bytecode analyzer
    ▸ Correctness issues , Bad practices,Dodgy
    code, Multithreaded Correctness, 

    Performance, Malicious Code
    ▸ any language which compiles to byte code
    

    View Slide

11. TOOLS OF THE TRADE
    PMD DEMO
    PMD - Source code analyzer
    ▸ unused variables, empty catch blocks,
    unnecessary object creation, etc.
    ▸ Java, JavaScript, Salesforce.com Apex,
    PLSQL, Apache Velocity, XML, XSL.
    

    View Slide

12. TOOLS OF THE TRADE
    INFER DEMO
    Infer - Source code analyzer
    ▸ Infer reports NPE and resource leaks in
    Android and Java code.
    ▸ Java, C/C++/Objective C
    

    View Slide

13. TOOLS OF THE TRADE
    CHECKSTYLE
    ‣ Checkstyle helps write Java code that adheres to a coding
    standard.
    ‣ It automates the process of checking Java code to spare
    humans of this boring (but important) task.
    ‣ Supports custom rules.
    

    View Slide

14. TOOLS OF THE TRADE
    CHECKSTYLE DEMO
    Outside of the defined style you can make it check and brake
    on :
    ‣ usage of android.util.Log
    ‣ code in comments
    ‣ Usage of system.out.println or e.printStackTrace()
    ‣ Discovery of specific comment type (TODO, STOPSHIP)
    ‣ Anything you put your mind to.
    

    View Slide

15. TOOLS OF THE TRADE
    ADDING CODE COVERAGE
    

    View Slide

16. TOOLS OF THE TRADE
    SONAR
    Sonar is an extremely popular tool.
    Some of the features it supports are :
    ‣ Analyzing more than 20 languages through plugins
    ‣ Doing in depth analysis of source or byte code.
    ‣ Distributed architecture
    ‣ Can comment on Pull requests
    

    View Slide

17. TEXT
    SONAR
    

    View Slide

18. TEXT
    SONAR
    

    View Slide

19. CHECK SUMMARY
    RESULTS
    All reports are finally accessible in your build folder
    ‣ Code coverage
    ‣ Javadoc
    ‣ Static code analyzers
    ‣ Tests and Test coverage
    

    View Slide

20. BUILD LOOP
    JENKINS / BAMBOO / TRAVIS / CIRCLE
    How do you re-define your build loop with all these tools
    ▸ ./gradlew clean
    ▸ ./gradlew check
    ▸ ./gradlew testCoverage
    ▸ ./gradlew generateJavadoc
    ▸ ./gradlew assemble
    

    View Slide

21. TIME FOR CHANGE
    HOW DO YOU WORK LOCALLY?
    ▸ Work on the problem
    ▸ Create clean code (or dirty and fix it afterwards)
    ▸ write documentation
    ▸ write tests
    ▸ Call gradlew check
    ▸ fix any pending issues
    ▸ Commit && Push
    

    View Slide

22. AUGMENT EXISTING
    WHAT TO DO ON A BIG PROJECT WITH EXISTING CODE
    ▸ Stop the bleed!! Manually Block PRs if checks fail
    ▸ Create a visibility monitor
    ▸ Use errors = warnings and present graphs
    ▸ Create a plan of attack (20% of the sprint for improving)
    ▸ Have a "fix warnings" day
    ▸ Make sure you have a continuous improvement approach.
    

    View Slide

23. LIVE EXPERIMENTS
    HOW MUCH TIME DOES IT TAKE TO ADAPT
    Preparation
    ‣ Painful few weeks (1 dev sprint) to make a starting point.
    ‣ 2 sprints to adapt (average time from my experience)
    After the adoption period
    ‣ 10 mins overhead per PR
    ‣ 50% - 80% time reduction per PR review
    

    View Slide

24. Q&A
    THANK YOU
    

    View Slide