Alcatel-Lucent CDC Workshop, Coaching & Knowledge Transfer Coding

Metrics & Kpi’s

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

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!

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

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

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

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

Architecture

Glance

Short & Long Term Benefits

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

Getting Started In Your Own Environment

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

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

Continuous Integration

 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

Project Dashboard: EMS

Project Dashboard: Reports

Refactoring

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.

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

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…

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

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.”

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.

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.

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

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

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

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.

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

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

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

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

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

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

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

Refactoring: practical  Visual Studio Solution: ItemSolutions.Refactoring

Questions  Any questions about the “Refactoring”?

Contact Item Solutions Plantin en Moretuslei Borgerhout   Speaker Kristof Rennen 