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
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
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?!
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
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)
6. TOOLS OF THE TRADE WHERE DO WE START ▸ Increase project visibility ▸ Add GIT branch protection ▸ Continuous issue discovery
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
8. TOOLS THE QUEST FOR THE RIGHT TOOLS We will be looking at how to integrate ▸ Lint ▸ Findbugs ▸ Infer ▸ Checkstyle ▸ Jacoco
9. TOOLS OF THE TRADE ANDROID LINT DEMO Checks : ‣ Java ‣ Resources ‣ Manifest and XML configs Approach taken : * Enable all * Warning = Error
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
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.
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
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.
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.
15. TOOLS OF THE TRADE ADDING CODE COVERAGE
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
17. TEXT SONAR
18. TEXT SONAR
19. CHECK SUMMARY RESULTS All reports are finally accessible in your build folder ‣ Code coverage ‣ Javadoc ‣ Static code analyzers ‣ Tests and Test coverage
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
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
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.
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
24. Q&A THANK YOU