Reducing technical debt in php

WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG

Reducing technical debts in PHP

Dr. Carola Lilienthal

[email protected], @cairolali

www.wps.de

Wolfgang Strunk

[email protected]

Sixt Leasing AG

2

Mobility services provider with highly attractive and customer centric product offering

Mid-sized and large corporates Private and business customersCustomer focus

Full Service Leasing Fleet ManagementLeasing / Vario Financing

+ Services Key products

~50k(2) ~31k ~16k(2)# of contracts 2014Total: ~97k(1)

Value proposition

One-Stop-Online-Shop for >30 OEMs• Price• Transparency• Convenience

OEM independent optimization of Total Cost of Ownership (TCO)• Know-how• Buying power• Outsourcing

Sixt Leasing AG

(1) Each Sixt Leasing vehicle is linked to one contract. However, not all contracts refer to a Sixt Leasing vehicle (e.g. Fleet Management). Hence, the total number of vehicles (~54k in 2014) is typically lower than the total number of contracts

(2) The contracts include new contracts (order book) for which the leased vehicle has not yet been delivered to the customer and pure service contracts

Contract CAGR 2012-2014

2% 111% 54%

Fleet Leasing Fleet Management Online Retail

26.04.2016 //// Seite 3WPS - Workplace Solutions GmbH

Software

Architecture

Requirement

Engineering

Control Room

and Interaction

Software

Development

Business software,

for joyfull work!

WPS – Workplace Solutions GmbH

4

Proprietary data and software development across the value chain as key competitive advantage

Quote Procurement Contract Length ReturnProcess Level 1

Process Level 2Tender &

Implementation

Vehicle

Order

Vehicle

Logistics

Vehicle

Handover

Final

InvoicesQuotes

Vehicle

ReturnInvoices

Vehicle

DisposalCustomer Service

User

Service

Order configuration Vehicle transport

Delivery station

Registration Fuel invoicing

Lease- & full service invoiceParking ticket management

Driver license check

Contract adjustment

Early return

Order management Handover to the station

Validity check

Customer/ User change

Delivery date coordination

Order changes

Reference calculation Cancellation

Incoming invoices (Check & enter, debit)

Pricing

Quotation negotiations

Breakdown service Return to retailer

Self-marketingAppraisalHandover to the retailer

Delivery

Collective invoicing

Return logistics

Return damage invoice

Final invoicing

Vehicle invoices

Fuel card service

Contract changes

Maintenance& attrition

Damage processing

Tire change & replacement

Residual value factors Order checks Work shop routing

Preliminary rental vehicle

Implementation

Damage invoicingActivation of contract

Return letter

Leasing request & contract check

Web portal & parameter keeping Reports & analyses (Customer demands)

Resignation from contract Cancellation by customerPurchasing

Software Modules

Customer facing

Internal

Source: Company information



Technical Debts ≠ Long-living


Measures against technical debts

� Regular architecture discussions

� Qualification for developers and architects

� Automated tests and continuously refactoring

� Regular architecture analysis and renovation


Architektur analysis: What is this?


Architecture renovation: how do we do that?

Refactorings

Analysis

+

Discussion

Determination

f measures

Implemented

ArchitectureReconstruction

Source-

Code

Planned

Architecture

Architecture

AlternativesViolations


Sotograph

� Plattform for Architecture

Renovation

� Commercial product since 2002

� Many customers, e.g.

Siemens, Lufthansa, HHLA,

Kühne&Nagel, Daimler,

Infineon

� Analyses Java, C++, C#, ABAP,

PHP and offers an open

interface for other parsers

www.hello2morrow.de


Components of sotograph

Java Parser

SotoReposi-

tory

C#Parser

Code-

Checker

C/C++Parser

Sotoweb

Sotoarc

Sotograph

Sotoreport

ABAPParser

PHPParser


Two goals for long-livingness

1) Maintainability

• Finding bugs quickly

• Make quick changes

• Understand and analyses quickly

• Reduction of complexity

2) Flexibility

• Variants of business processes

• Changing requirements

• Service orientation and scalability

• Modularity (Baukastenprinzip)


70%

20%

10%

Code verstehen

Problem lösen

Code schreiben

How do we spend our time when programming?

Code comprehension

Problem solving

Writing code

@ www.tomfreudenthal.de


Well-formed complex structures = saving time!

Cognitive Mechanisms

HierarchiesChunking Schemata


@ naturfotographen-forum.de

Marion Meixner

Zusammenhängende Einheiten

@ www.fotocommunity.de

Jan Schwensweger




Well-formed

architecture

Modularity


Modularity

�High Cohesion and lose Coupling

�Responsibility Driven Design

�Separation of Concerns

�Single Responsibility Principle





Well-formed

architecture

Modularity


Hierarchies

� �




Well-formed

architecture

ModularityHierarchical

Layerng




Säumer Schema

@ Daniel Rihs






Well-formed

architecture


Layerng

Pattern

Consistency

30

Hierarchies on the architectural level: layers and modulesTechnic

al Layeri

ng

Domain Layering

Presentation

BP & Activity

Domain

Data


Two dimensions in on architecture

Technical layering Domain layering

Tree violations

that are easy to

resolve

Difficult

violations

One component

cuasing several

problems

One component

causing a

problem


Domain layering is missing

Technical layering No domain layering

Some violations

of the technical

layering

Allmost all

domain

components

need each other


Hierarchies on class level

Influences:

� maintainability

� reusability

� testability

� modularisation

� Pattern conformity


119 classes from 4 components

+ 28 other classes


327 classes from 8 components

That all need each other





Well-formed

architecture


Layerng

Pattern

Consistency


Uneven Modules

One big Monolith with several little satellites

950.860 LOC

84.808 LOC


Uneven Modules

9 Components = 17 Subsystems





Well-formed

architecture


Layerng

Pattern

Consistency


Pattern on the architectural level: four modules

Module

green

Module

purpleModule

orange

Module

blue


Pattern conformity: Bad example


Pattern conformity: Good example


Pattern on class level: design pattern and pattern languages

User Interface

Domain

Application

Domain ModuleDomain Module

Window

GUI

Model

ViewControl

ValueObject

Service

BusinessObject

Sch

ich

tun

g d

urc

h M

ust

er


Pattern conformity: Good example

☺ 90% of the source code can be assigned to pattern

☺ 0,1% violations between the pattern

��

��


Pattern conformity: the discovery of a pattern language

☺ 80% of the source code can be assigned to 23 pattern

☺ 4% violations between the pattern






Layerng

Pattern

Consistency

� Consistent and

integrated pattern

� Use a pattern

language

� No cycles neither

on architectural

level nor on class

level

� responsibility

� coupling

� size

� interfaces


Process of analyses and renovation of architecture

Thank you for your attention!

www.langlebige-softwarearchitektur.de

Dr. Carola LilienthalMitglied der

Geschäftsleitung

[email protected]

www.wps.de

+49 170 184 77 11

Diplom-Informatikerin

@cairolali