so you just inherited a $legacy application
Post on 08-Jan-2017
372 Views
Preview:
TRANSCRIPT
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
Doctrinehttp://www.doctrine-project.org
Local Dev Environments
Physical Hardware
Vagrant (Virtual Machines)
Docker (Containers)
Physical Hardware
Vagrant
PuPHPet.com
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:
top related