3. Ατζέντα
● Ποιότητα κώδικα (τι, πότε, πως και γιατί;)
● Οι 7 άξονες της ποιότητας και το τεχνικό χρέος
(technical debt)
● Εισαγωγή στο SonarQube
● SonarQube demo time
6. Τι είναι ποιότητα κώδικα;
“Μία ένδειξη για το πόσο γρήγορα οι
developers μπορούν να προσθέτουν
επιχειρησιακή αξία σε ένα σύστημα”
7. Γιατί να μετράμε;
● Ο κώδικας είναι η καρδιά κάθε συστήματος
● Οι developers δε γράφουν νέο λογισμικό. Απλά
συντηρούν “legacy” συστήματα
● Ένα σύστημα (σχεδόν) ποτέ δε θεωρείται
ολοκληρωμένο
● Χωρίς μέτρηση δεν υπάρχει (ουσιαστική
βελτίωση)
9. Πότε είναι η ώρα να
μετρήσουμε και πως;
● Από την ημέρα #0 του project
● Συνεχόμενα
● Πρόληψη vs Πυροσβεστικής
● Ιεράρχηση και προγραμματισμός
10. Τι να μετρήσουμε;
● Απόλυτοι αριθμοί; (Σχεδόν) άχρηστοι
● Εξέλιξη στο χρόνο; Σίγουρα!
● Μετρικές; Ποιες;
● Ας γνωρίσουμε τα 7 θανάσιμα αμαρτήματα των
developers
11. Οι 7 άξονες της ποιότητας
Uni
t
Tes
ts
Technical Debt
Πιθανά Bugs
i
Cod
s
rule
ng
α
ητ
ότ
οκ
πλ
λυ
Πο
Διπλός Κώδικας
εκμ
Τ
ρί
η
ση
ω
Σχ
εδί
ασ
η
12. Technical Debt
“If the debt grows large enough, eventually the company will
spend more on servicing its debt than it invests in increasing
the value of its other assets”
Steve McConnell
(συγγραφέας του βιβλιου code
complete)
13. Έτσι μοιάζει ο κώδικας
όταν δεν πληρώνουμε το
τεχνικό χρέος
16. Τι είναι το SonarQube;
● Ελεύθερη πλατφόρμα ανοικτού κώδικα για
διαχείριση ποιότητας κώδικα
● Παρέχει στιγμιότυπα της ποιότητας του κώδικα
● Παρουσιάζει τάσεις της ποιότητας
● Καταγράφει μετρήσεις για τα 7 θανάσιμα
αμαρτήματα
● Μετράει και κατηγοριοποιεί το τεχνικό χρέος.
17. Πως λειτουργεί;
● Αναλύει πηγαίο και byte κώδικα
● Υπολογίζει εκατοντάδες μετρικές
● Συνδέει τις μετρικές με στιγμιότυπα ποιότητας
● Προβάλει τα αποτελέσματα σε dashboards και
widgets – προσβάσιμα από browsers
18. SonarQube για τα πάντα...
● Αρχικά σχεδιάστηκε για Maven Java projects
● Σήμερα υποστηρίζει πάνω από 20 γλώσσσες
Επί πληρωμή : ABAP, C, C++, Cobol, Natural, PL/SQL,
Visual Basic
Δωρεάν : C++, C#, Flex, Groovy, Android,
Javascript, PHP, Python, XML, Web(xhtml, jsp , jsf),
Erlang
19. … και για όλους
Για developers. Γράφω “καλό'
κώδικα; Πώς να βελτιωθώ;
Για testers. Ποια τμήματα του
συστήματος δεν έχουν unit tests
Για architects. Έχει “σπάσει” το
αρχικό design; Τι γίνεται με την
πολυπλοκότητα;
Για managers. Δώστε μου νούμερα!!
Πάμε πάνω ή κάτω;
22. Η μεγάλη εικόνα
•
Διαχείριση και μείωση του Technical Debt σε
συνεχη βάση (Καθαρίστε την κουζίνα καθημερινά)
•
Ενεργοποίηση των devs από την #1 μέρα (Δεν
πλένουν μονο οι μανάδες τα πιάτα)
•
Κόκκινος συναγερμός όταν το Technical Debt
ξεπερνά τα άνω όρια (όταν δηλαδή αφήνει κάποιος
την κουζίνα σε κακά χάλια)
23. I have a dream…
...that one day code
quality management
will be as much as
important and
essential is today
source code
management
Nothing is more important than code. Not tools, methodologies, practices.
When to consider a system under maintenance ? As soon as it’s publicly available it become “legacy” or system under maintenance.
The broken windows theory was first introduced by social scientists James Q. Wilson and George L. Kelling, in an article titled "Broken Windows" and which appeared in the March 1982 edition of The Atlantic Monthly.[1] The title comes from the following example:
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.
Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.
Just mention some of the metrics provided by SonarQube.
The kitchen metaphor. Clean up the mess from previous dinner (old feature) before starting to cook again (new feature)
Technical debt is about people not about technology. When to deal with the technical debt?
All that “temporary” experimental code, duplicated code, lack of test coverage – all that stuff will really slow you down later when you build the next feature.
Discuss the “good” and “bad” Technical debt. Debt baseline, Debt ceiling,
Dashboards for central control (mention that all 7 sins exist in dashboard )
Drill down to every metric shown in dashboard
Time Machine for historical data
Can you fix everything?? (no)
What about legacy applications?
Differential views in dashboards (Issues, Test Coverage , arrows, trends )
Breakdown by module, package file
The value of comparing with previous snapshots / versions
Explain why it’s important the + - in issues when viewer differentials.
Code coverage on new code. Great for legacy systems.
Code reviews for issues. Plans ( different plans for current version, next version or future)
Global dashboards ( fully configurable )