Your SlideShare is downloading. ×
Thessaloniki rb-24
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Thessaloniki rb-24

176
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
176
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Elaborate a little more here.
  • 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 )
  • Transcript

    • 1. Μειώνοντας το Τεχνικό χρέος(Technical Debt) με το
    • 2. To SonarQube κι εγώ
    • 3. Ατζέντα ● Ποιότητα κώδικα (τι, πότε, πως και γιατί;) ● Οι 7 άξονες της ποιότητας και το τεχνικό χρέος (technical debt) ● Εισαγωγή στο SonarQube ● SonarQube demo time
    • 4. private String _ugly_name; private String ANOTHER_$UGLY___NAME; private static String am_i_static; public void please_work(ArrayList objects){ for (Object object : objects){ if (object == null){ String toString = object.toString(); } else am_i_static = object.toString(); doSomething(object); } } private void doSomething(Object object) throws NullPointerException { throw new NullPointerException(object.toString()); }
    • 5. What is code quality?
    • 6. Τι είναι ποιότητα κώδικα; “Μία ένδειξη για το πόσο γρήγορα οι developers μπορούν να προσθέτουν επιχειρησιακή αξία σε ένα σύστημα”
    • 7. Γιατί να μετράμε; ● Ο κώδικας είναι η καρδιά κάθε συστήματος ● Οι developers δε γράφουν νέο λογισμικό. Απλά συντηρούν “legacy” συστήματα ● Ένα σύστημα (σχεδόν) ποτέ δε θεωρείται ολοκληρωμένο ● Χωρίς μέτρηση δεν υπάρχει (ουσιαστική βελτίωση)
    • 8. Η θωρεία του σπασμένου παραθύρου
    • 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. Έτσι μοιάζει ο κώδικας όταν δεν πληρώνουμε το τεχνικό χρέος
    • 14. “Καλό” & “Κακό” Technical Debt
    • 15. Πως χειριζόμαστε το Technical Debt
    • 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. Δώστε μου νούμερα!! Πάμε πάνω ή κάτω;
    • 20. Διαχείριση ποιότητας • • • • • • Dashboards Ιστορικά Δεδομένα Διαφορικές προβολές (Differential Views) Συγκρίσεις Αναθεωρήσεις κώδικα (Code reviews) Πλάνα ενεργειών
    • 21. DEMO TIME
    • 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
    • 24. Ευχαριστώ 1 ppapapetrou76 @ppapapetrou76 http://www.linkedin.com/in/ppapapetrou