On 12/02/2010 08:56 AM, Michael McHugh wrote:
Hi Folks,
Company I work for licenses the source code of a legacy system that has been
drip feeding updates over the last few years and I have finally been given
approval to migrate it to the Agavi framework (license allows us to change any
code).
I'm curious on any advice, tips, tricks or thoughts any others may have from
experience doing a similar thing. A couple of my ideas on this are below..
1/ The idea is to initially wrap the application in the framework and slowly
refactor/extract parts of the original code into Agavi. I was thinking of using
a default route that passed to a module/action pair of something like
Legacy/Default that simply called the appropriate legacy script.
2/ Legacy code has significant use of globals and $_POST, $_GET, $_REQUEST and
$_COOKIE variables...<shudders> so in factories.xml would need to set the
'unset_input' parameter to false on the AgaviWebRequest object. Until this was
addressed anyway.
And just to vent because I am the only coder on this project - this legacy
beast uses include('someFunction.inc') as if it were equivalent to
someFunction() ;)
Hi,
Sorry for the late reply. Indeed, I have faced this task in the past.
Migrating PHP4 applications to Agavi is, well, an interesting task. In
my case, as refactoring proceeded incrementally, a business necessity
arose to add new features and bug fixes to the new codebase that's been
refactored. So, refactoring and development of the new codebase were
done simultaneously.
Briefly, what I did is this:
1. The old application (the "source") was put under version control.
I prefer git because of its cheap branching, rebasing and other
/nice/ features.
2. A new blank application (the "destination") was created. A point
of note: the default setting of strict validation was removed from
it temporarily, as it made refactoring very inconvenient.
3. The database configuration was prepared in the destination
application to match that of the development and production
environment of the source application.
4. I've went clicking around the old application, collecting its URL
structure. This URL structure was then recreated in the
destination app's routing map, with approximated names for modules
and actions that weren't created yet. This gave me a rough layout
of the destination application. In fact, Agavi's routing was a key
mechanism in the whole refactoring endeavour.
5. I've converted the master templates, CSS layouts and other minimum
outfit so that the destination app looks and behaves
6. I've written a similar authentication system and configured
logging for the destination application. I've configured session
sharing and database so that whatever's initialized in the source
app is also accessible in destination (in my case, I had to use
the horrible PEAR DBDO/MDB2 as the source app used it for schema
and relationship management)
7. At this point the destination application resembled a refactored
skeleton for the source one, but did not carry any actual business
logic from the source application.
8. I've ported a single often used feature (an Action in Agavi terms)
into the destination application.
9. Using webserver URL rewriting and virtual hosting magic, I've
deployed the destination application along with the source one in
production under the same URL hierarchy as the source application
so that the new actions I implement overshadow the existing ones.
10. One by one, I've moved features from source to destination,
without the users being able to take note, and organizing the
priorities in such a way that newly requested features always fall
on the code that's already been ported. As features migrated, I
physically removed the code from the source application.
Eventually I've arrived to the point at which the destination
application fully replicated the existing functionality (while having a
much more consistent structure), so I could turn off the legacy codebase
entirely. At this time, I was able to start shaving the architectural
warts, features that weren't needed any more, writing validation and
unit tests. All in all, I was able to incrementally move the application
from chaos to Agavi right in front of people's eyes and no one noticed.
Notice that the key difference in my approach was that I did not "wrap"
the source application in the framework; rather I had the new
application imitate the environment of the old one, and the two were
connected through URL mappings, a shared database and a logon session
(I'm sure there was more to it than just this I just dont quite remember
the details). This proved to be a great decision as I didn't have to
muck with the old code at all; and working on rather small units of code
(usually a single Action at a time) I was able to iron out most of the
moronic idioms from the code as I went.
In any case, good luck and Ceiling Cat bless you!
_______________________________________________
users mailing list
[email protected]
http://lists.agavi.org/mailman/listinfo/users
