1. Alcatel-Lucent CDC Workshop, Coaching & Knowledge Transfer Coding

2. Metrics & Kpi’s

3. Quantify your processes  Build information  Versioning information  Code analysis  Genesis information  Operational metadata

4. Benefits of quantification  (Implicit) measurement of development quality   leads to optimization  Individual developers  Group processes   control your development process  Establish SLA’s with third parties!

5. Visualize your metrics  Use simple and easily accesible representations  Genesis, Glance, charts

6. Use metrics wisely  As always... Just the numbers are not enough  Build kpi’s based on combined metrics  Keep the ‘common sense’

8. What  Data analysis architecture  Enables visualization of development process data  Cube explorer  KPI browser  Reporting engine

9. Benefits  Fast feedback  Metrics over time   measure evolution   enables optimization  Central repository  Combine project metadata and operational data   leads to very detailed view on development process

10. Architecture

11. Glance

12. Short & Long Term Benefits

13.  Short term  Optimize quality per project  Long term  Install a true software factory  Uniform processes, metrics, delivery  Overall : SAVE MONEY

14. Getting Started In Your Own Environment

15. Source Control  Centralized code repository  Easy accessible code through check-out / check-in  Subversion, CVS, Team Foundation or any other alternative

16. Tools  Testing Framework (Nunit)  Mocking Framework (Rhino Mocks)  IoC Container (Castle Windsor)  Build Server (Team City)  Genesis

17. Continuous Integration

18.  Triggered by changes in the code repository  Builds almost every check-in  Steps  Get latest code  Builds a new version  Runs tests  Runs genesis  Packages a new version  Generates reports

19. Project Dashboard: EMS

21. Project Dashboard: Reports

22. Refactoring

23. One step beyond…: Refactoring  Now that we have a good set of test and a good way to follow up on things, let’s go one step further: improve the quality of our code.

24. Refactoring  Let’s explain WHY we should refactor  Let’s explain WHAT refactoring is

25. Why refactor  A machine is NOT the only one that needs to understand your code… … your colleague and even yourself in a few months time should too!  That’s why YOU should write high quality code, that is readable, understandable and maintainable… …by using refactoring techniques…

26. Why refactor  Improves the design of software  Makes software easier to understand  Helps in finding bugs  Helps in programming faster

27. What is refactoring?  Martin Fowler:  “Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”

28. What is refactoring?  Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of transformations can produce a significant restructuring.

29. What is refactoring?  Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

30. How to refactor  Find a code smell  Code that stinks  Bad code  Refactor it using refactoring methods Code smell Refactor

31. How to refactor  Refactoring is a continuous process  “Add function” OR “Refactor”. Change hats!! Add Function Refactor

32. Code smells  Parts of the code that “stink”  Parts of the code that need refactoring  Most important code smells  Duplicate code  Long methods  Large classes

33. The tight link with unit testing  How are unit tests involved in refactoring?  It’s easy: How can you change your code without knowing you break something???  Thus: refactoring is only possible when you have a good set of unit tests, ensuring you that you do not break anything while improving it.

34. Refactoring  The Holy Bible  www.refactoring.com www.refactoring.com  Golden advice:  Buy the book and read it!  It will change your life as a developer!!

35. Duplicate code: problem  Some code is needed in more than 1 place  The easiest way, at first sight, is to copy-paste the code  This results in bad maintainability: if this code has to change, it has to be changed in multiple places  It’s likely to forget to change some parts so bugs are introduced easily

36. Duplicate code: solution  Same code in multiple methods in same class: Extract method  Same code in multiple methods in subclasses: Extract method in both classes and Pull up method  Same code in unrelated classes: Extract class and use this class in both methods

37. Long method: problem  Long methods are hard to understand  Long methods are hard to maintain  Long methods are susceptible to bugs

38. Long method: solution  Replace long method by calls to other “private” methods  Use Extract method to create delegation to smaller methods

39. Large class: problem  Classes that try to do too much  Each class must have its own responsibility

40. Large class: solution  Use Extract class  Use Extract subclass

41. Refactoring: practical  Visual Studio Solution: ItemSolutions.Refactoring

42. Questions  Any questions about the “Refactoring”?

43. Contact Item Solutions Plantin en Moretuslei 155 2140 Borgerhout  +32 3 236 64 03  info@itemsolutions.com Speaker Kristof Rennen  kristof.rennen@itemsolutions.com