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. 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
  2. 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?!
  3. 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
  4. 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)
  5. TOOLS OF THE TRADE WHERE DO WE START ▸ Increase

    project visibility ▸ Add GIT branch protection ▸ Continuous issue discovery
  6. 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
  7. TOOLS THE QUEST FOR THE RIGHT TOOLS We will be

    looking at how to integrate ▸ Lint ▸ Findbugs ▸ Infer ▸ Checkstyle ▸ Jacoco
  8. TOOLS OF THE TRADE ANDROID LINT DEMO Checks : ‣

    Java ‣ Resources ‣ Manifest and XML configs Approach taken : * Enable all * Warning = Error
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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
  15. CHECK SUMMARY RESULTS All reports are finally accessible in your

    build folder ‣ Code coverage ‣ Javadoc ‣ Static code analyzers ‣ Tests and Test coverage
  16. 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
  17. 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
  18. 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.
  19. 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