I've just started work at a small start-up company who mainly uses PHP to develop their front-end apps. I had no prior PHP experience before joining, and this has led to my apps becoming large pieces of spaghetti code. I essentially started by adding code to implement an initial feature, and then continued to hack in more code to implement further features – without much thought for the overall design.

The apps themselves output XML to render on small mobile devices.

I recently started looking into frameworks that I could use. I reckon an advantage would be that they seem to force developers to modularise their programs using good-practice design patterns. This seems great for someone in my position. The extra functions they provide, for example: interfacing with databases in such a way as to make SQL injection impossible, would be very useful too.

The downside I can see is that there will be a lot of overhead for me in terms of the time taken to learn the framework itself (while still getting to grips with PHP itself). I'm also worried that it will be overkill for the scale of the apps we develop. They tend to be programs that interface with a fairly simple back-end DB, and will generate about 5 different XML screens. Probably around 1 or 2 thousand lines of code. The time it takes just to configure the frameworks may not be worth it. The final problem I can see is that developers in the company – who have to go over my code, and who do not know the PHP framework I may use – will have a much harder time understanding it.

Given those pros and cons, I'm still not sure on what the best course of action will be; so any advice will be greatly appreciated.

Using a framework doesn't mean good object oriented code at all. Most people fall for that and think that since they are using class then they are doing it right. From a fellow PHP developer make sure your code is SOLID and learn when to use the design patterns and GRASP principles
–
SongoOct 15 '12 at 16:52

4 Answers
4

I think you're actually asking two questions, which I'll try to split out.

I reckon an advantage would be that they seem to force developers to
modularise their programs using good-practice design patterns. This
seems great for someone in my position. The extra functions they
provide, for example: interfacing with databases in such a way as to
make SQL injection impossible, would be very useful too.

The question is about frameworks conceptually. What you have said is absolutely true. Some frameworks encourage the use of MVC which, in my opinion, is a great way to separate the logic of your code and make it maintainable (abstract is better). There's no net worth to coupling your code to a particular database engine when you can write code once, which will work against any of the popular ones.

The downside I can see is that there will be a lot of overhead for me
in terms of the time taken to learn the framework itself (while still
getting to grips with PHP itself). I'm also worried that it will be
overkill for the scale of the apps we develop.

This part is about frameworks for your project specifically. This is more difficult for me to answer, but I certainly think you should have a good strong look. Even if you only have a 1 model (one table with your data in), 5 controllers (one for each page of data that you want to manipulate) and 1 view (which just takes the data and spits it out as XML), I still think it'll be worth it. Why? Because it's a common and scalable structure. If you find that, in a few years, you end up with 50 XML pages, 50 JSON pages and 50 text pages - you'll really wish you weren't hacking away at the XML code to get it to json_encode, or toying with strip_tags because your business logic is tightly coupled with the view.

Also, once you use some of the automagic features if your framework like forms, authentication, ACL and the like, you'll never want to bore yourself by writing this yourself again. It will just take usage of one of these for you to realise that the time you spend reading the documentation is severely outweighed by the fact you barely need to test the end result compared to if you had written the feature ground-up.

The time it takes just to configure the frameworks may not be worth it.

Then pick a lightweight and almost-zero configuration framework. I've used CakePHP quite a lot, but I've heard good things about CodeIgniter too. Cake, for example, has one real file that you need to edit: database.php. Everything else is optional, and comes in a debugging mode which you can turn off later once you want to deploy your application.

The final problem I can see is that developers in the company – who
have to go over my code, and who do not know the PHP framework I may
use – will have a much harder time understanding it.

I wouldn't even consider this as a hurdle (that said, if you have management policies about these things then you should - I am assuming you have been given a new project with the freedom of how you want to approach it). If the developers assigned to review your code cannot get their head around a simple MVC structure, they are in no position to review code. Frameworks are very well divided: the code your write and the code they give you are in completely opposite locations (essentially). All they are really looking at for you is 3 folders: models, controllers, and views where they should be able to look at each file and see if the logic is what they'd expect.

In the long run, frameworks are the way to go. If you only want to write a script quickly that you'll only be using for a few days, then don't bother.

The first step should be to consult the more experienced PHP developers at your company. Possibly they already use some framework, or at least have a standard pattern for code organization. They might be able to guide you to a framework that's particularly suitable for your app.

Personally, being new to the development environment, I wouldn't feel comfortable making a unilateral decision to use a new framework.

The company is a small startup. From the code I've had to modify so far, everyone seems to lay out their programs in very different ways. No one is using a framework currently; it seems the newer programmers – like me – don't know how, and the old-school developers tend to program in the same style they have since the mid-nineties. But yes, it's something I should discuss with people first; I think it could help bring some consistency between our code if others do decide to adopt one.
–
FractalOct 17 '12 at 11:35

@Fractal: In that case I absolutely would suggest finding a good framework and doing your best to sell the other developers on it. It sounds like they really need something like that; having a bunch of programmers doing everything differently is no way to run a company. Good luck!
–
ChrisOct 22 '12 at 13:27

Great answer by Jay, I wanted to indicate that there is another possibility though.

It sounds like key things that you require from the framework are standards and structure.

I am not anti-frameworks, but you don't 'need' one, you might benefit from one though.

You could in fact create your own MVC with very little code, and use a common DAL at the back-end (likely based on PDO - low learning curve - or an ORM / ActiveRecord pattern).

The advantage is that you would not have to learn a framework, neither would any of your colleagues, but you would learn how to architect a simple one! Plenty of examples on Google. This might be a good exercise for you, as it requires you to understand the MVC (which is in fact hugely simple in concept), which in turn will help you understand the benefits, as you have thought them through in detail.

Choosing the above route may allow you to keep more of your existing source as you can consider the migration requirements.

Frameworks IMHO really come into their own when trying to maintain common standards across teams and to save you creating error prone complex common functionality. They can be restrictive especially when migrating an existing system. So you might make this decision based on the perceived future complexity of your application, if it remains simple you don't need a framework, if it grows, you might wish you had you used one from the start.

For keeping the learning smaller - try to learn CodeIgniter (if you are on a tight time schedule to learning, choose CodeIgniter) and/or even limit to refactor the code in to proper object-orientantion and a nice class structure. I wouldn't say that your application will be magically more maintanable by a framework.

I don't know how or if you use object-oriented techniques but shouldn't it be sufficient?
Keeping the database logic (fetching/inserting/updating) in a separate class(-es) (= Model). These could be "basic" operations for data-access.

A more finished class would be all the data the specific page needs to have, combining several model-classes to a view-specific-rendering. Still it should use only code, no html!. (= viewmodel).

And having each "page" in a separate file (view), handled by a specific "viewmodel" for all the data.

This kind of behaviour is called MVVM - model-view-viewmodel - (http://en.wikipedia.org/wiki/Model_View_ViewModel).

These are small steps that will improve your site significantly if you don't already use them.