Programming PHP without MVC, classes or framework: rewrite or continue on new features?

Question

I have been programming for several years now, and back then (learning PHP) I've didn't learn to program using classes, MVC-logic or using any frameworks. I found my self solving my problems very well using my own functions.

Eight months ago I was recruited to a start-up, to develop a huge social platform. I have been working there for several months now, and built up a huge website with various complicated features (+35k lines of code I guess), and I could see my self continue like this. Everything is coded without any framework, no classes or with MVC-logic, since I didn't have the time to learn it (we had to move fast).

I do write everything in functions, and put a lot of effort in well documenting/describing my code as well as organizing it beautifully and easy-to-read.

However, it is top of my list to learn Classes > MVC > Laravel (or any other) framework. But I just can't see my self stopping now, learning above list, and then rewrite all code. This would simply push us back in time, and in the start-up we're moving fast and have many deadlines for new features/ideas/development.

I've spoken with many people regarding this, and people say a lot of different things. Some say it's a matter of taste, and you'll be able to move on with it. Others say it's incredibly stupid, you're not scaleable, you're never get serious funding, you're the only one who ever be able to work on the project, you should stop and start learning it now, etc.

Am I doomed? I feel lost. My personal opinion on this is, that even though it is a huge system already, it is still a MVP and I guess at some point in the future we would rewrite the code anyways. This is, if we're at such a successful stage in our venture and growing very fast / getting funding / etc.

Answer 1

Learning OOP is definitely worth it. Passionate hireable developers are always willing to learn to expand their knowledge, specially when you can save time in the long run. I would agree more with the second group of people:

Others say it's incredibly stupid, you're not scaleable, you're never get serious funding, you're the only one who ever be able to work on the project, you should stop and start learning it now, etc.

That's a bit harsh, but the reality is, the more you know, the more you scale. Serious funding is often surrounded by hype, and procedural code is unfortunately not cool enough. OOP and frameworks are.

Am I doomed? I feel lost. My personal opinion on this is, that even though it is a huge system already, it is still a MVP and I guess at some point in the future we would rewrite the code anyways [...]

Large procedural code bases are not uncommon, see WordPress. OOP really helps to abstract and organize your code without relying on procedural conventions (although MVC frameworks have a whole different set of conventions). WordPress started a migration process, that's still going on today. With such large projects all you can do is upgrade your system, step by step, testing that nothing breaks, and keep re-factoring, forever, as you'd introduce new features that will need refactoring later on.

But no, you're not doomed, just a little bit late to the whole process. Learn what you can when you can; less is better than nothing. The learning curve when learning new programming paradigms, or languages, is often steep at first, but after that first hiccup it'll be smooth sailing, and you'll start to really appreciate the difference it can make on your code, and the difference it will make when others read your code.

Edit: Just to clarify, I'm not suggesting the current system needs to be OOP, or that it needs to be built from scratch. Any system is going to be re-factored, at some point, and you may need to break compatibility with previous system, and that's fine if the project requires it; you can have a deprecation cycle as well. What I'm suggesting is to slowly introduce OOP as you refactor your current code, namespaces, etc.

Answer 2

It's probably a little too late to move wholesale to a MVC framework. Particularly if you are still trying to get the project online.

What I would recommend you do is focus on learning OOP, and then starting to migrate your existing functionality into a class structure. Then, if you do decide down the road to migrate to a 3rd party framework, you should be able to reuse a lot of the code.

Answer 3

(Moved from Stack Overflow following question closure).

I think it depends. If the code is modular already, and markup/logic is well separated, it may be better not to port to a completely different system. You need to consider the impact on the existing business, and whether taking devs off new feature projects is worth it in your case.

A better way to do it may be to find a bolt-on library that separates logic from code, and use that initially just for your new code. Then, as you find time, start porting your old screens to it, and get each one live as you finish it. The result then is that you iteratively improve, rather than trying to do it in a "big bang", and thus is less risky.

I work on a large PHP system where it has been quite hard to make a business card to move to any decent MVC-like system. We'd like to, but it would be 6-12 months of development work, and although I tend to personally view the cost/benefit favourably, the client does not, and of course it's clients/managers that make these decisions!

The solution in my case has been to write a trivially simple object-based controller system, which we tend to use for new development going forward. It's not as nice as Symfony2 or Laravel, but it's a significant step towards modularity and maintainability, and is good enough.

That all said, if you're not using objects at all, I'd say that was quite unusual. They are a very natural and useful mechanism to organise your application, and would suggest that this should be your first port of call when deciding how to improve your codebase.

Answer 4

This project in particular might be a tad too large to be completely rewritten, but consider it a lesson.

MVC frameworks have many purposes:

• They handle a lot of the boilerplate (routing, templating etc)
• They decouple the various steps between the request and the response, allowing you to inject all kinds of functionnality very easily.
• They separate different concerns: views are separate from the model and the business logic, so you can completely redesign the site without coding skills.

This can be achieved without a framework, but there is no point in doing so. They usually save you a lot of time and effor, and you should absolutely consider them for your next project.

If your current project is maintainable, then you should not waste so much resources rewriting it and instead consider slowly migrating things as you touch them. Is it worth the investment? Only you know.

Answer 5

Rewriting a large system such as yours just to organize the code in classes at first doesn't seem too bad, but unless you are going to be rewarded for your efforts by then having a system that has much less bugs, is easier to extend, more optimal and so on, I would say that your time is better spent maybe thinking about writing extensions to your application using classes at the very most.

It is true that most frameworks and large applications favour oop code organisation, but it certainly isn't a requirement. Having learned to love functional programming languages, especially ocaml, I personally feel that classes are inferior to functions, and now that php offers better use of functions and closures, there really is no damning reason to use classes at all. This may be blasphemy for most, but I believe it to be the case.

Classes do have their uses but they are not a necessity. Let's look at some use cases where the traditional use of classes and their equivalents, namely static methods and instances.

1. Static Methods.

   Using namespaces, it is more than possible to have the same functionality as a static class method, and since it is possible to have different namespaced methods grouped across different files, arguably much more flexible and extendible.

2. Instance State.

   An instance of a class contains it's own internal state. This has always been touted as one of the benefits of using OOP. It is equally viable to use closures to do the same just as equally and has been used successfully in many other languages to great success.

So, my advice is to keep trail-blazing. You may me grateful over time as people start migrating to your coding style.