2. From theory ... into practice
• Learning experience : IS Management at Binus
MMSI. (2008-2010)
• Working experience :
• IT Manager at Prasetiya Mulia. (2009)
• Senior Java Developer at Knowment AIE.
(2010)
• Project Manager at Telkomsigma (2011-now)
Experience without theory is blind, but theory without experience is mere
intellectual play. – Immanuel Kant
3.
4.
5. Scenario 1:
• Your team doesn’t collect code
metrics from projects. Therefore, your code
base could be getting worse and worse
without anyone ever noticing. You might
start noticing when the technical debt (we will
elaborate on this concept later) has reached a
certain level where it’s tooexpensive
to address them, given the time and budget
constraints.
http://blogs.sourceallies.com - Akrem Saed
6.
7. The Answer
• Collecting code metrics continuously can give
your team the advantage of keeping the technical
debt of your code base under control. For
example, you can make it a rule that you don’t
allow your code base to extend beyond a certain
threshold in terms of some metric values.
Whenever that threshold is reached you are
notified immediately through
your continuous build.
• Implements LEAD MEASURES
8. Scenario 2:
• Time and time again I’ve witnessed teams that
start refactoring because they are convinced
the code base was bad in terms of
performance, brittleness, instability, difficulty to
maintain and/or to extend. While our intentions
are good, we don’t know what part of the code
base is responsible for the issue we encounter.
Hence, there is a good chance changes will be
applied to the wrong code. Or we end up
refactoring the right code in the wrong way. Or
we only fix part of the problem.
http://blogs.sourceallies.com - Akrem Saed
9. The Answer
• This is where metrics and tools like Sonar can
help.
• Sonar points out the parts of the code that
are causing problems.
• Once these issues are identified they can be
prioritized and added to the backlog.
• Sonar helps teams identify and address issues
with confidence.
10. Scenario 3:
• Another team is the best in the world and has
remarkable instincts in identifying and correcting
issues, but they fail to track the quantity of
issues fixed in their triumphant voyage.
• Let’s face it, managers and team leaders would
definitely appreciate having a clear idea of how
many improvements were made with their
resources and budget.
• They also want to know which issues still need to
be fixed in the future.
http://blogs.sourceallies.com - Akrem Saed
11. The Answer
• Now, if you preserve a snapshot of metric
values before the voyage, you could report
something like this “… before our code base
was 75% compliant with the company’s best
practices and now it’s at 95%”.
• Sonar helps you track yourimprovement
progress.
12. If you can’t measure it, you can’t improve it. - Peter Drucker
13.
14. Why Sonar?
• Free
• Quantitative measurements of code quality
• A set of measurement metrics
• Discourage bad practices
19. Broken Window Theory
• Don’t leave “broken windows” (bad designs, wrong
decisions, or poor code) unrepaired. Fix each one as
soon as it is discovered. If there is insufficient time to
fix it properly, then board it up. Perhaps you can
comment out the offending code, or display a “Not
Implemented” message, or substitute dummy data
instead. Take some action to prevent further damage
and to show that you’re on top of the situation.
20. Broken Window Theory
• We’ve seen clean, functional systems deteriorate pretty
quickly once windows start breaking. There are other
factors that can contribute to software rot, and we’ll
touch on some of them elsewhere, but neglect
accelerates the rot faster than any other factor.
• You may be thinking that no one has the time to go
around cleaning up all the broken glass of a project. If
you continue to think like that, then you’d better plan
on getting a dumpster, or moving to another
neighborhood. Don’t let entropy win.
21. • Continuously collecting and reviewing
software metrics can help identify andfix
“broken windows” before they affect other
windows.
• The longer a bad design and bad code are left
unfixed, the more vulnerable your code is to
receiving additional hacks. Leads to bigger
Nonconformance Cost.
http://blogs.sourceallies.com - Akrem Saed
23. Sonar is Not Alone
• Sonar uses various static code analysis tools
such as Checkstyle, PMD, FindBugs, Clover to
extract software metrics, which then can be
used to improve software quality.
31. Sonar Metric Definitions
• http://docs.codehaus.org/display/SONAR/Metric
+definitions
o Complexity
o Design
o Documentation
o Duplications
o Reviews
o Rules
o Size
o Tests
