Leaning on the two Ts is a talk on improving code quality, personal practise and developing good habits using tools and techniques. Attendees of this talk will learn about my experience when learning to use static analysis tools (i.e. SonarQube) and some of its features. In addition also find out how it can be used to improve your code quality and personal practice. A number of tools will also be mentioned and how to include them in your practise. Powerpoint-like presentation sharing information from a perspective higher than just the use of tools, although no runtime implementation or live coding will be performed. Live examples might be shown depending on time constraints. The presentation is definitely for intermediate and experienced Java developers, but also beginner developers who would like to know more about code quality and tools that can be of help. Also for those already using static analysis or other tools in anger or just casually. Especially those who would like to know how to use tools as a medium to learn from.

1. @theNeomatrix369
Are you pairing with tools to
improve code quality ?
Leaning on tools & techniques to improve code quality

2. @theNeomatrix369
About me
Mani (@theNeomatrix369)
● LJC Associate
● Adopt OpenJDK and JSR (JCP Member)
● blog: http://neomatrix369.wordpress.com
● github: http://github.com/neomatrix369
● bitbucket: https://bitbucket.org/neomatrix369
Avatar: courtesy of Recworks: Dan Smallman @dsrecworks

3. @theNeomatrix369
- I’m only sharing my learning experience - YMMV !
- Experimental yet practical methods
- Learning via validating and verifying
- A silver bullet to solve all problems
- One shirt fits all solution
- Not about any specific product
Disclaimer

4. @theNeomatrix369
Agenda
- How it all started for me...
- First steps to learning to use these tools...
- Inventions
- Observations
- Introspection
- Discoveries
- Conclusion

5. @theNeomatrix369
How it all started for me...

6. @theNeomatrix369
My first computer - 8088 processor
(8-bit processor)
My first game - Digger (not PacMan)
Mid-1990s

7. @theNeomatrix369
Between 2000-2010
Career started as a hobby - years later become
a profession

8. @theNeomatrix369
Early 2010
Desire…more
knowledge,
experience & skills

9. @theNeomatrix369
Communities
...met dev. communities in London and other parts of Europe!
LSCC

10. @theNeomatrix369
Sowing of seeds...

11. @theNeomatrix369Source: SonarQube (aka Sonar)
What does code quality mean to you ?
Is it the seven axes of quality ?

12. @theNeomatrix369
How do we improve quality ?

13. @theNeomatrix369
Pair programming is good...

14. @theNeomatrix369
...but not always available...

15. @theNeomatrix369
Then I had an idea...

16. @theNeomatrix369
Why not use tools...

17. @theNeomatrix369
First steps to learning to
use these tools...

18. @theNeomatrix369
Treemaps are awesome...
10,000 feet view !

19. @theNeomatrix369
Dashboard - my own Quality metrics

20. @theNeomatrix369
Issue violations & Duplications
Checkstyle, Findbugs, PMD rules

21. @theNeomatrix369
What is Cyclomatic
Complexity
or
Complexity ?

22. @theNeomatrix369
In simple words, it is the
number of pathways
due to decision logic in a software
program.
See Wikipedia definition

23. @theNeomatrix369
Complexity See Definitions glossary

24. @theNeomatrix369
Refactoring saves the day...
Higher complexity (CCI: 4)
void doSomethingBasedOnCurrentState( int state ) {
switch ( state ) {
case INACTIVE: //doSomethingForInActiveState(); break;
case ACTIVE: //doSomethingForActiveState(); break;
case UNKNOWN: //doSomethingForUnknownState(); break;
}
}
Lower complexity (CCI: 1)
public enum CurrentState {
INACTIVE { void doSomething() {} },
ACTIVE { void doSomething() {} },
UNKNOWN { void doSomething() {} };
abstract void doSomething();
}
CCI Source: SonarQube (Complexity scores)

25. @theNeomatrix369
Refactoring resources...

26. @theNeomatrix369
Test coverage -
unit & integration tests
Hint: EclEmma, JaCoCo and IntelliJ Code Coverage

27. @theNeomatrix369
Performance tuning tools(short and long feedback loops)
- Application behaviour
- GC behaviour (on the JVM)
- Early or late feedback (during
development, or post- development)
- Profiling
Some known tools: Java Mission Control, Java
Flight Recorder, jconsole, GC Viewer, VisualVM,
HeapAnalyzer, PerfAnal, JAMon, HPJMeter,
HonestProfiler, mjProf, Eclipse Memory Analyzer
(MAT)

28. @theNeomatrix369
Performance tuning tools(short feedback loop)
Profiling tools
- Honest profiler
- mjProf
- Eclipse Memory Analyzer (MAT)
- others

29. @theNeomatrix369
Performance tuning tools(short feedback loop)
Profiling tools
XRebel
(lightweight)
runtime java
profiler

30. @theNeomatrix369
Performance tuning tools(short feedback loop)
JITWatch* - @chriswhocodes
Understand...Java HotSpot Just-In-Time (JIT) compiler...
program execution.
Hot Method too big - among other JIT optimisation errors
Java 7 and Java 8 core methods above the default hot method inlining threshold
*an Adopt OpenJDK F/OSS project

31. @theNeomatrix369
Performance tuning tools(long feedback loop)
Censum - jclarity.com
- GC Analysis, similar to GC Viewer
- Additional metrics and graphs
- Built-in analytics,
recommendations & heuristics

32. @theNeomatrix369
The others...
Google CodePro
Coverity ThreadSafe
IntelliJ IDEA Squale
Veracode

33. @theNeomatrix369
Collaborate...
share, crowd-source, machine learning...
(Hippie completion)

34. @theNeomatrix369
Inventions...

35. @theNeomatrix369
Strategies (checklists)
[ ] Strategy (method in the madness)
[ ] Strategy (interesting, ear-marked)
Find the checklists in the Resources section at the bottom

36. @theNeomatrix369
Continuous Inspection
Individual
inspections
(local first)

37. @theNeomatrix369
Continuous Inspection
(local first)
Some more individual inspections

38. @theNeomatrix369
Rule of thumb
Metrics Rule Mitigating action
Method complexity >= 6 pathways Refactor: split method
Class complexity >= 60 pathways Refactor: split class
LCOM4 >=2 responsibilities Refactor: new class / subclass
RFC per class > 40 connections
(both ways - afferent &
efferent)
Refactor: reduce dependencies
and dependents, split class
Source: SonarSource resource, Book: SonarQube in Action

39. @theNeomatrix369
Observations...

40. @theNeomatrix369
Repetition...helps build
muscle memory

41. @theNeomatrix369
Kata (型) ?
きょうしつ (kyoushitsu)

42. @theNeomatrix369
Katas - individual parts
issues violations
duplications
code (test) coverage
mutation testing
quickcheck
immutability check
complexity check
performance check

43. @theNeomatrix369
Introspection...

44. @theNeomatrix369
Trust but verify
Trust your tool(s)…
…believe in your method(s)
Adopt advice from peers & experts…
...but also evaluate it yourself

45. @theNeomatrix369
Do these factors make up
quality ?
developer: knowledge and skills
x
tool: tunability, features & capabilities
x
(environment & team)

46. @theNeomatrix369
(when you take a plunge)
...its not just about tools, there is more….
Discovery…

47. @theNeomatrix369
Discovery…
...firstly a tool is only
a temporary scaffolding…

48. @theNeomatrix369
Discovery…
...its about methods and
techniques...
(because tools are only a
dumb conduit)

49. @theNeomatrix369
Discovery…
(...if you dive deeper…)
its about the practise
and developing good habits
"I'm not a great programmer; I'm just a good programmer with great
habits.” Kent Beck, http://en.wikiquote.org/wiki/Kent_Beck

50. @theNeomatrix369
Realisations...
Writing good quality code takes
practice, effort and time

51. @theNeomatrix369
Quality is a concerted effort of not just a single
developer but a team of developers !
Realisations...

52. @theNeomatrix369
- Repetition
- Measuring progress
- Early detection
- Short feedback loop
- Reliable pairing
- Filling the (missing) gap
- Powerful & effective ally
Conclusion

53. @theNeomatrix369
Summary
● Personal story
● Various methods & techniques: processes
● Strategies (checklists)
● Inventions & observations: continuous inspection (local first) & katas
● Discoveries and Realisations
● (My) conclusion

54. @theNeomatrix369
Gratitude - big thanks !
...to the dev communities of London and Europe!
LSCC

55. @theNeomatrix369
Q & A
Keep them coming !

56. @theNeomatrix369
Its time to share your methods and
help improve our craft !
Please tweet your feedback at
@theNeomatrix369

57. @theNeomatrix369
Devoxx UK -
TBA 2016
Socrates UK -
TBA 2016
Conferences

58. @theNeomatrix369
Let’s change the Java ecosystem, together!
Daniel Bryant @danielbryantuk
Mani Sarkar @theNeomatrix369
With support from the JCP, London Java Community and Java communities worldwide
@adoptajsr
@adoptopenjdk
members@adoptajsr.java.net
adopt-openjdk@googlegroups.com
adoption-discuss@openjdk.java.net

59. @theNeomatrix369
Resources
● SonarQube resources
● SonarQube Nemo project
● Discussions on Sonar on JavaRanche
● Installing SonarQube (formerly Sonar) on MacOsX Mountain Lion
● Using SonarQube on MacOsX Mountain Lion
● SonarGraph (http://www.hello2morrow.com/products/sonargraph)
● Jitwatch: http://github.com/AdoptOpenJDK/jitwatch
● QuickCheck (https://bitbucket.org/blob79/quickcheck)
● Mutation Testing (http://pitest.org/ or http://ortask.com/mutator/)
● Mutability Detector (https://github.com/MutabilityDetector/)
● AssertJ - fluent assertions for Java (plus other fluent libraries)
● Censum (@jclarity product - see http://www.jclarity.com/censum/)
● Profilers: HonestProfiler, mjProf, Eclipse Memory Analyzer (MAT)
● Books: Sonar in Action (http://www.manning.com/papapetrou/), Software
Craftsmanship by Sandro Mancuso, Uncle Bob’s Clean Code

60. @theNeomatrix369
Predecessor to this presentation...
http://bit.ly/1lk8NDW
to improve code quality !
SonarQubetm

61. @theNeomatrix369
Strategy (method in the madness)
[ ] Unit & Integration test coverage:
EclEmma, JaCoco, IntelliJ Code Coverage check
[ ] Most violated rules (Blockers, Critical, Major, Minor violations)
[ ] Duplication removal - DRY
[ ] Complexity (package-, file/class-, method-levels)
[ ] Performance: profiling (memory, cpu, hardware)
[ ] Performance: GC analysis*, JMH benchmarking*
* Java/JVM platforms only

62. @theNeomatrix369
Strategy (interesting, ear-marked)
[ ] Analyse & apply Squale reports
[ ] Apply SonarGraph
[ ] Apply Mutation testing (i.e. PITest, Mutator)
[ ] Apply generative tests (QuickCheck)
[ ] Apply Mutability Detector library
[ ] Analyse using JitWatch (improve JIT attempts)
[ ] Analyse using Censum (improve GC)

63. @theNeomatrix369
Quality of Music - truth table
Quality of instrument
(material)
How tuned the
instrument is?
Skills & experience of
the performer
Quality of music
(outcome)
Bad Not tuned Not skilled / Skilled Very Bad
Bad Tuned Not skilled / Skilled Bad
Medicore Not tuned Not skilled / Skilled Below Average
Good Tuned / Not tuned Not skilled / Skilled Average
Good Tuned Skilled Good
Very good Tuned Highly skilled Very good

64. @theNeomatrix369
Novice to expert...
In the beginning, learning from past experiences,
building up knowledge and experience with
repetitions, finally excelling with your own efforts...

65. @theNeomatrix369
Layers of quality
Continuous Deployment*
Continuous Integration*
Code quality
Tools & Methods
(Developing) Good Habits

66. @theNeomatrix369
Layers of quality (contd.)
Continuous Deployment*
Continuous Integration*
See what Dr. Daniel Bryant has to say about the above:
http://slidesha.re/1rKdOdU
http://slidesha.re/VwKDB0
(Devops the TDD approach)