Day 13 and I want to work a bit on my goals. Today, I start reading Modernizing Legacy Applications in PHP. My goal is 50 pages which means up to Chapter 7 about writing tests.
I really like the different approaches to why rewriting is dangerous. I’ve seen some rewrites myself which miserably failed or took extremely long. I know about one rewrite which took around 14 months and by the time the rewrite was complete is was already dated. But at least the code base was better. On top of that I took around a year to re-fix the bugs that were reintroduced, add business rules, etc.
- A VCS
- Modern PHP version
- Style guide (PSR-2)
- Test suite (Characterization test: output doesn’t change) – Selenium/Codeception
After implementing an autoloader the next step is to consolidate all class files into a central directory and remove the includes for these class files, one by one.
For all functions without classes create a class with (static) methods and do the same again.
The next step is to eradicate
global. First, we put the
global stuff into the constructor and assign it to a field. After that works fine we are going to use DI and create factories.
The general guide line is: Don’t use new outside of factory classes (exception: SPL and Exceptions).
I looked at my code again and found several instances where a factory would be useful and implemented it!
Now it’s time to write tests. If we’re done with that we can go to the embedded database stuff. Every database access, csvs, etc. should be in its own class called a gateway.
You could either organize by implementation layers (MySQL, CSV, etc. classes) or by domain entities (recommended).
Next, we’re going to extract the domain-logic into transaction classes. This will probably take the longest.
After that we can extract the view. One tip I liked is to use the output buffer and save the generated view into a var for testing!
The same with the action logic.
He then creates a public directory and leaves stuff like includes non-public. Then a front controller can be added and finally DIC.
Wow, lots of things to do! I can only imagine doing this on a 500k+ legacy project. It’s a short book without fluff. Really good book in my opinion!
Playing with Neo4j -[:USING]- PHP
I heard about graph databases – especially Neo4j – but never really took a look into it. Let’s see!
As a friend of graphs I quite like the idea. You basically have nodes which can store some information. And you also describe some relation between them. And that’s it!
Also pretty cool. There’s an event system which allows you to execute code on some predefined events!
Graph databases really seem to shine for complex relationships. Something to keep in mind.
How You Can Architect and Develop Enterprise Mission-Critical Applications with Domain-Driven Design
- Bounded context: constraint the model (what belongs and doesn’t belong?)
- Ubiquitous language: Terminology within a specific meaning
- Main goal: Unify the mental model (domain expert = developer)
Language isn’t just nouns.
Context mapping: Maps relationships between bounded contexts
- Ports & Adapters: Architecture; Domain Model takes Adapters to connect to outside ports (DB, I/O, etc.)
- Domain Event – Event within a domain
I watched most of the talk at 1.5 to 2x speed and I still felt that it was slow. The content is good though, however it’s probably better to read something to save time.
Being grumpy for fun and profit
So far I can only agree on his points. His points on scalability are interesting. Definitely a good watch!
Workflows of Refactoring
A Fowler talk which means lots of new terminology.
- Litter-Pickup Refactoring aka. Boy scout rule: Always leave something cleaner as before
- Comprehension Refactoring You don’t understand the code and spent time figuring it out.
- Preparatory We should have done it this way.
It’s funny that he’s making such a science out of it. However, if nobody wouldn’t think that it is a science he wouldn’t tell it. Somehow I’m quite happy that I never followed the dogma.
Also interesting that the IT world is rediscovering Kaizen. That’s how I saw refactoring all the time. Probably thanks to my ignorance of the exact definition.
One good advice about refactoring is: Refactoring is about economics.
We’re doing this do deliver more functionality easier.
The software journeyman’s guide to being homeless and jobless
The first 10 minutes are pretty light-hearted but there’s some insight in this talk:
We got nothing done because we were afraid of failure.
I can get over that, that’s alright!
He said that about VisualStudio but that’s with a lot of things in life. I’m notorious for that. I don’t like something – mostly because I never really looked into it. I get over it. I actually learn about it. I start to understand it. And I actually can form a valid opinion. Sometimes I even start to love it.
We’re developers and we can get it done with enough time.
So, I’ve made some progress on my project. The example files are working and the server is working. I want to refactor some method which does the routing. And then write an interface for the comments.
Learn a bit more about legacy systems and how to handle them
- Learn a bit more about MySQL
- Learn Symfony2
- Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security, caching, i18n)
- Get a bit more exposure to OOP and OOD
- Watch one video per day on average
- Reading Modernizing Legacy Applications in PHP [done]
- Learn a bit more about legacy systems and how to handle them
- Watch one video per day on average [38 of 75]