So You Just Inherited a $Legacy Application...

https://joind.in/talk/4d6d9

Joe Ferguson

Who Am I?

Joe Ferguson

PHP Developer

Twitter: @JoePFerguson

Organizer of @MemphisPHP

@NomadPHP Lightning Talks

PHP FIG Secretary

Passionate about Community

For Further Reading

leanpub.com/mlaphpleanpub.com/minimumviabletests

Legacy Applications

First: A Warning

“There are no solutions, only trade offs”

- Joe Ferguson

- Paul M. Jones

- Thomas Sowell

What is a "Legacy" application

Legacy is often used for an older production application that was written before, or without regard for modern technologies or practices.

If you ask Wikipedia…

"... no-longer supported …"

"... maintained by an administrator that did not develop the code …"

"... supporting older file formats ..."

https://en.wikipedia.org/wiki/Legacy_code

Modern Interpretation

"... source code inherited from someone else …"

"... source code inherited from an older version of the software ..."

Some people say…

"Any code in production is not legacy”

"Any code written X years ago is legacy"

Legacy is all these things

As we talk about Legacy code here, we're really talking about all of these definitions

This process is not Legacy Specific…

Inheriting a Legacy App

Precontemplation or Shock/Disbelief

Contemplation and/or Anger

Determination and Bargaining

Action and Reconstruction

Maintenance and Acceptance

Precontemplation or Shock/Disbelief

This is the initial "what is this?!"

That’s now how this works!

Precontemplation

Not ready for change (project, code base, etc)

Usually you don’t know the depths of issues

Can sometimes lead to assuming the worst

Usually this is the shortest phase due to business needs

Shock/Disbelief

This is where the WTFs and the WTHs should be left

Try to work through any negativity here

Be positive about the previous developer’s intentions

Contemplation and/or Anger

This is the planning phase

Try to get all of your ager at the code base out during this phase, it will help

you see the path forward.

Taking stock of what we’re working with

Initial Project Overview

Is there a framework?

Is there a coding standard?

Is there any autoloading?

How are dependencies behind handled?

Is there an ORM or how is the database being utilized?

Is there a development environment?

Is there a framework?

Is there a coding standard?

No Standard? No problem!

Is there any autoloading?

There is a PSR for that…

How are dependencies behind handled?

Is there an ORM or how is the database being utilized?

Is there a development environment?

Tools to help

PHP Coding Standards Fixerhttp://cs.sensiolabs.org/

PHP Coding Standards Fixerphp-cs-fixer fix app --dry-run

PHP Mess Detectorhttps://phpmd.org

PHP Mess Detectorhttps://phpmd.org

$ phpmd app html cleancode --reportfile report.html

Warning about Automating Code Changes

Composerhttps://getcomposer.org/doc/01-basic-usage.md

Doctrinehttp://www.doctrine-project.org

Propelhttp://propelorm.org

Local Dev Environments

Physical Hardware

Vagrant (Virtual Machines)

Docker (Containers)

Physical Hardware

Vagrant

PuPHPet.com

Docker For Developers

leanpub.com/dockerfordevs

Determination and BargainingDecision making and triage time

Triage

Address any critical things found in Contemplation phase

PHP version issues

Fixing critical vulnerabilities

You have a plan and now you need to estimate this plan.

I hate estimating

nomadphp.com/2016/04/06/stop-multiplying-4/

Lightning talk by Chuck Reeves (@manchuck)

Short and sweet talk about how to do better estimating

No Question Left Behind!

The application has no framework, We’re going to use a micro framework as we refactor.

The application has no autoloading, But we’re using Composer

Dependencies are checked into version control, But we’re using Composer

There is no ORM, but we’re going to use Propel

We have no dev environment but we’re going to use Vagrant

Proof of Concept

Any new things introduced should be tested to ensure functionality

Build out a small example of an area you or the team doesn't fully comprehend so you can address any questions that may arise

Bargaining

Getting stakeholders on board with your estimates

Do the decisions made thus far make business sense?

Are there any doubts in the plan?

“We should just rewrite the app”

"This would be so much easier in framework _____________”

Why not rewrite?

Progress halts entirely

Business logic is rarely reused

Most of the time is getting back to current functionality

Why you should refactor

Progress continues

Business logic reused

Modernizing functionality instead of recreating

Make Decisions

Build Proof of Concept(s)

Ensure stakeholder buy in

Avoid the allure of green fields**

** in some cases a rewrite is warranted

Action and Reconstruction

Existing Tests

This is great!

Review the tests to get an idea of coverage

Passing tests become your control for any upcoming changes

Confidence++

No Existing Tests

Not the end of the world!

Inspect the code base, was it written to be easily testable?

Could you easily mock dependencies?

Untestable Code

Not all code is testable

If you can’t easily unit test the code base, consider alternatives

Functional testing and Acceptance testing are valid options

Acceptance Testing

NOT a replacement for Unit Testing

Test large parts of your application at a time

Can be harder to pinpoint error location

Gives large code coverage in short amount of time

Digging into the Code

Code Consolidation

Digging into the Code

Code Consolidation

Replace globals with DI

Digging into the Code

Code Consolidation

Replace globals with Dependency Injection

Write tests

Digging into the Code

Code Consolidation

Replace globals with Dependency Injection

Write tests

Extract SQL (to ORM or other)

Digging into the Code

Code Consolidation

Replace globals with Dependency Injection

Write tests

Extract SQL (to ORM or other)

Extract Business Logic (To domain logic)

Digging into the Code

Code Consolidation

Replace globals with Dependency Injection

Write tests

Extract SQL (to ORM or other)

Extract Business Logic (To domain logic)

Extract Presentation Logic to Views (Twig, Blade, etc)

Digging into the CodeCode Consolidation

Replace globals with Dependency Injection

Write tests

Extract SQL (to ORM or other)

Extract Business Logic (To domain logic)

Extract Presentation Logic to Views (Twig, Blade, etc)

Extract Action Logic (To Controllers)

Digging into the CodeCode Consolidation

Replace globals with Dependency Injection

Write tests

Extract SQL (to ORM or other)

Extract Business Logic (To domain logic)

Extract Presentation Logic to Views (Twig, Blade, etc)

Extract Action Logic (To Controllers)

Write (more) tests

Maintenance and Acceptance

Maintenance and AcceptanceCode Consolidation

Replace globals with Dependency Injection

Write tests

Extract SQL (to ORM or other)

Extract Business Logic (To domain logic)

Extract Presentation Logic to Views (Twig, Blade, etc)

Extract Action Logic (To Controllers)

Write (more) tests

Maintenance and Acceptance

Adding Features

More New Code

Less Refactoring

Maintain your processes

Continuous Integration

Revisit Acceptance Tests

Resources / Q & AModernizing Legacy Applications In PHP - Paul M. Jones

https://leanpub.com/mlaphp

Minimum Viable Tests - Chris Hartjes

https://leanpub.com/minimumviabletests

Code Style https://github.com/FriendsOfPHP/PHP-CS-Fixer, http://editorconfig.org

php mess detector https://phpmd.org

Autoloading PSR-4 https://getcomposer.org/doc/01-basic-usage.md

ORMs http://www.doctrine-project.org http://propelorm.org

Docker https://leanpub.com/dockerfordevs, Vagrant https://puphpet.com

Feedback!

https://joind.in/talk/4d6d9

Joe FergusonTwitter: @JoePFergusonEmail: joe@joeferguson.meFreenode: joepferguson

Contact Info: