Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Make or Break

Tancho
April 11, 2017

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.

Tancho

April 11, 2017
Tweet

More Decks by Tancho

Other Decks in Programming

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