wow, seems you have some task cut out there....
I suppose the best approach depends on what the expected life-time of
the application is, if it needs to work for some time still and
especially if there are more features likely to be added, in this case
to zf2-ize it makes sense (to me) because otherwise the technical debt
is just going to grow..and grow...
In the past when confronted with spaghetti-legacy-code applications and
having had to add functionality to it, or fix bugs, I found a carefully
exercised test-driven approach useful..
If it's of any interest, here's a link to a book that I found personally
quite insightful in regard to this as it is all about test-driven
refactoring of legacy code (it's also available on safari books):
http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
I suppose it comes down to analyzing risks and benefits...
hope this helps at all, good luck!
On 11/02/14 16:18, dennis-fedco wrote:
I have this existing application with existing feature for product X. You
select product options from menu options and it generates a PDF. Code that
runs this spans throughout a 6000-line technology soup PHP file collection.
It is a complex intertwined procedural/oo aplication (600K lines) that uses
outdated and questionable programming practices, has no clear separation of
components, and more so represents files spanning thousands of lines of php
code with SQL, HTML, jQuery, and CSS, with functions all rolled into one.
Each file calls functionality in some other file, and tracing a single
feature through these can be quite an exercise (thereby creating its own
entangled architecture of sorts). It is somewhat modularized, but not in a
ZF2 module sense. To call a certain module, you can say
router.php?m=<module_name>, which effectively calls a certain file.
My task is to make this work with a new product Y that uses different
parameters and different custom computations to create the PDF for Y.
Original intent was to rewrite this entire application in ZF2, but this is
prohibitive at the moment due to the customer needing functionality *now*,
and re-architecting this app in ZF2 will probably take years.
Normally, I would Copy and Paste code that runs X into some place and call
it Y, and then go over the copied code and change parameters and
computations accordingly, to make feature Y work. Problems: code
duplication, code divergence, lack of testing, no DI, no separation, etc.
So here is the challenge -- *I want to take steps towards ZF2*, and ZF2 can
call any existing code
<http://zend-framework-community.634137.n4.nabble.com/Best-Practices-on-incorporating-non-OO-non-ZF2-code-into-ZF2-app-tp4661601p4661602.html>
... but ... how?
Do I just create an "empty facade" ZF2 wrapper around these files? Maybe
create custom routing that somehow works seamlessly with existing
application? These are not cleaned up library code files, these are actual
business logic files, embedded in long spaghetti code PHP . Putting a ZF2
facade around them seems a bit superfluous as it won't magically make them a
ZF2 application, but maybe is a start. I am not entirely sure HOW to
ZF2-ize my task, or if it will be good to do it in the first place. I think
I may just succumb to copy and paste approach and fail to take steps towards
ZF2, unless there is some sort of a nice solution that I can implement here
that hopefully will not take too much time when compared to the copy and
paste approach.
Do I try to ZF2-ize this app or just forget about it? What if something
else, like decoupling/organizing/refactoring this application is a better
mindset to take in the long term, in a sense preparing the codebase for ZF2
instead of thinking about ZF2-ing it from the get go?
--
View this message in context:
http://zend-framework-community.634137.n4.nabble.com/I-have-a-challenge-for-ZF2-tp4661664.html
Sent from the Zend Framework mailing list archive at Nabble.com.
-----------------------------
Registered Office: 15 Stukeley Street, London WC2B 5LT, England.
Registered in England number 1421223
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited. Please note that the information
provided in this e-mail is in any case not legally binding; all committing
statements require legally binding signatures.
http://www.weareifp.com
--
List: [email protected]
Info: http://framework.zend.com/archives
Unsubscribe: [email protected]
