Story of modernising a legacy app in PHP

PHP Konf Istanbul, 2014

Transcript

1. Adam olacak kod Story of modernising a legacy app in PHP
2. Old code • 150000 lines of code • 90% of code is procedural • No coding convention • No separation of concerns
3. Old code • Architected over several years • global variables all around • Core of the system was a collection of include files • Mixed-up aggregation of PHP, HTML, SQL, JS, and CSS
4. Old code • No unit tests • No environment aware • Offensive programming • Lack of error reporting, logging
5. Its too hard • Understanding logic • Designing anything new • Debugging, fixing bugs • Using new technologies
6. Making life easier, not a priority • "We can fix it later" • "It works!" • "Cutting and pasting code is faster than refactoring code" • "We do not pay you to write nice code. We pay you to get job done"
7. Writing from scratch, Part 1 • As a REST API ! • Written in 4 months • 15000 lines of code
8. First days • Include hell still exists • Big picture problem • Context-Switching • Knowledge problem
9. We can’t use a framework • Using PHP 5.1 in production (lately upgraded to 5.4) • Finding a compatible modern library is hard (Thanks to PHP_CompatInfo) • Missing features (namespaces, LSB, closures, traits, generators) • Working with same environment is impossible
10. Core refactoring • Autoloader implementation • Error handling • Logging (ported from Slim\Log, after replaced with Monolog) • DB Abstraction (derived from Doctrine\DBAL \Connection)
11. Core refactoring • Replace global w/ Dependency Injection • Environment aware behaviours • Common exceptions • Request lifecycle (routing, request, response)
12. Extracting procedural code to MVC • Defining endpoints • SQL Queries • Business logic • Validations
13. Part 2, Frontend • Custom Symfony2 Kernel ! • Written in 2 months • 30000 lines of code
14. Frontend • Top of Symfony\HttpKernel • Basically, Symfony2 without bundles • Enhancements for FrameworkBundle • Rapid Application Development (minimal planning in favor of rapid prototyping)
15. Frontend • Accelerates development processes • Shorter notations (routes, templates) • Guzzle for talking with API • Uses YAML files for configuration
16. Frontend • Heavy usage of IoC and Event Dispatcher • Twig as a templating engine • Monolog for logging • Custom (shallow) directory structure
17. Why REST? • Separation of concerns • Scalability and performance (Easier to scale horizontally and vertically) • Caching (Eliminates some client–server interactions) • Portability and simplicity (Replaced and developed independently)
18. Concerns for a good REST API • Fine grained resources • Versioning • Authorization • Sensible HTTP status codes
19. Thanks • Osman Ungur • github.com/o