Related
I started learning PHP awhile ago. I guess I'm fairly okay in it. I want to write a Content Management System, just as a project for myself, however long it may take. To be more specific, a simple gaming CMS where users can log in, post clan statistics, post in a forum, have user profiles, upcoming matches etc, various other modules you can install or code yourself. It's been done before, but I feel like I would learn a lot by going through with this.
To the experienced coders:
What is required to undertake such a project?
Any framework preference?
Is OOP necessary?
Are there certain ways to go about making such a large-scale project?
I've heard of various frameworks like CakePHP, codeigniter, and Zend, but I'm not sure what I should make of it.
The most important step in any project is PLANNING.
Plan everything you can , database (tables , columns , relations) , process-flow and such on.
Nothing is necessary but OOP is recommended because:
You won't get lost in your own code
Easy to edit and to add (reflexable for changes)
Cakephp , codeigniter are frameworks and they will save you lot of development time.
Instead of writing classes for each type of models you have (posts , members ...)
you run a simple command and it will create a basic app for your needs.
From my personal experience so far i would suggest you (at least) try making the system on your own since the experience and knowledge gained throughout the process of creating complex systems is by far the best hands on practice you will ever get.
Whether to use a specific framework or not is particularly up to you and whether you feel up to the task of achieving the system development on your own, since using a framework would also require learning the specific framework as well.
For OOP i would highly recommend it since it makes everything a lot easier. If you've never worked with object oriented principles before, you might find it a bit challenging at the beginning, but once you get over the learning curve you'd be more than satisfied with the result, with what you've learned and how easy and organized your whole system will look, especially when you have to make small changes or updates.
Since we are talking about a relatively large system as you suggest, i personally cant stress enough, how important planning and analysis is. Try to write down in details all the data you will need, make drafts and plan your database tables as thorough as you can since if during the process you find out that you've forgotten something or something just doesn't feel right, you might have to recreate classes, databases etc. to make it all run smoothly.
OOP is in the end a matter of preference, but there are a few notable advantages. The very first one that comes to mind is security. Parametized queries with mysqli, which are designed to function in an OOP kind of way, transactions, if you will have any.
If you want CMS, then you will also probably have to display quite a lot of data from the database, which will require pagination. Instead of having to re-write a "procedural" pagination algorithm, you could approach everything with OOP with a single class.
Ultimately, it is still a matter of preference but as far as I know, oop comes with many many advantages in real world applications. Good luck with your project!
I'll just reiterate what's already been said here and say this: OOP is a utility, and never a requirement. I'm an OO person myself and I tend to think easier in those terms after having done it for years, but I don't think I've come up across more than a couple of things that I don't think I could have done without OO practices (one of which being a particle effects engine, which is kind of a given).
That being said, there are definitely times where OO is more a hindrance than an boon. What you need to do is sit down and really visualize your project as a whole. When you're looking at the big picture, do you see things as encapsulated objects? Will you have one block of code that you will be using lots of times over to describe things that are similar but slightly different? Or, is your project a bit more linear where you can see most of your scripts running in the traditional "top-down" format?
Well, the point of OOP is to make programming more similar with the real world. In the real world, you're dealing with objects. Your job is an object of class Job, you are an object of class Employee which extends the class Person, you go home to an object of class Apartment which is contained in an object of class Building, which is contained in an object of class Block.
My point is, the point of OOP is to make life easier for you, you can designate a forum post as an Object, as you can for users and whatnot. The whole structure of data you can create in OOP is far more complex, and easy to understand than procedural PHP.
Eventually, it's all in your preference, but yes, if you asked me whether I'd recommend you use OOP on a project of this scale, I would definitely say yes.
As for your other questions:
What is required to undertake such a project? - Planning, and lots of it. Plan ahead anything you might need (in terms of database, existing projects/classes, files, pages). Also plan in for extensibility, to add modules and tables in the future.
Any framework preference? - I'm not a huge fan of frameworks, but I suggest you do learn the concept of MVC and single point-of-entry.
i think framework will help you a lot.. i mean various repetitive task can be easily omitted
and for a large project OOP is highly recommended for simplicity without OOP your code will be very evil and very hard to maintain
You should first look for some good framework - working from beginning is quite difficult. You should first create some kind of block diagram of necessary parts of your application and corresponding database/tables.
OOP is recommended because it could save you a lot of time.
One good framework look here: http://code.google.com/p/phpstartapp/
Please allow my intro to properly define the scope of my question:
I'm still very new to the programming world. This all started for me when I had an idea for a software program, but no programming experience. I ended up going the outsourcing route to get the program, and after almost a year, we do have it live and functioning.
This specific program is written with php and is 100% web-based. We're using lots of ajax, jQuery, etc.
Now a year into it, I have been learning and learning wherever I can (lots of learning here!!!) I'm mainly focusing on Java now to build up to Objective-C and the iPhone fun (probably like 99% of all other newbie programmers out there).
I'm really learning so much, and one of the biggest things I'm learning about is proper commenting and scalability.
I'm seeing now that this job we just finished is very sorely lacking in both those areas. I am wanting to add and build upon this program, and not only do I not have much experience, but I'm seeing that it's really hard for me to even get an idea about the functions without these comments...
So my question is-what is the best course of action to begin to pick up the pieces on this program? A full re-write is out of the question, and I don't think is needed.
I'm sure this is not the first time some newbie programmer, software developer has been down this path...what do others do here?
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
If this is the wrong place for this question (and I understand it may well be) can someone point me to where this would be more appropriate?
Thanks!
Joel
We call it "refactoring" and it's an important part of programming.
First, you must have a rock-solid set of automated tests. Usually we have unit tests that we run with a unit testing framework.
http://www.testingtv.com/2009/09/24/test-driven-development-with-refactoring/
Then you can make changes and run the tests to confirm that nothing was broken by your changes.
In some cases, you have to "reverse engineer" the tests around the existing programs. This is not very difficult: you have to focus on the interfaces that are "external" or "major" or "significant".
Since you're reverse-engineering, it's hard -- at first -- to determine what should be tested (because it's an important external feature,) and what should not be tested (because it's an implementation detail.)
I'm really learning so much, and one of the biggest things I'm learning about is proper commenting and scalability.
First, I'm curious what you've learned about "proper commenting" as this varies drastically. For some, it's documenting every class and function. For others, it may be documenting every line of code or no code at all.
After having gone through some of the different phases above, I'm with Uncle Bob Martin who, in Clean Code, says that you document decisions, not what the code does. The code itself should be readable and not need documentation. By adding comments describing behavior, you've created duplication that will eventually become out of sync. Rather, the code should document itself. Using well-named functions and variables help describe exactly what the other intended. I'd highly recommend Clean Code for a full discussion of these concepts.
As for scalability, it's usually something that you want to build in. Scalability might be a function of good design, or a proper design for the requirements, but poor design will make scalability a nightmare.
I'm seeing now that this job we just finished is very sorely lacking in both those areas. I am wanting to add and build upon this program, and not only do I not have much experience, but I'm seeing that it's really hard for me to even get an idea about the functions without these comments...
I see this as an indicator of one of two things:
That the code isn't well written. Yeah, that's highly subjective. -OR-
That you don't yet fully understand everything you need to. -OR-
A little bit of both.
Writing good, intention-revealing code is hard and takes years of practice.
So my question is-what is the best course of action to begin to pick up the pieces on this program? A full re-write is out of the question, and I don't think is needed.
As other posters have mentioned, Refactoring. Refactoring is the process of changing code to improve readability and usability without changing functionality. Get a good book on refactoring, or start reading everything you can online. It's now a critical skill.
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
Unfortunately it is. It takes a lot of diligence to avoid falling into this trap. Try to make your code a little bit better every day.
I don't know about this being the wrong place or not, but I'll answer as I can:
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
Yes, in my experience this is very common. I have been doing contract work for over 10 years, and I can't count the number of times I've had to come in and clean up something hastily put together to either make it scale or to be able to add functionality onto it. This is especially common when you outsource the programming to another company, the incentive there is to get it working and out of the door as quickly as possible.
So my question is-what is the best course of action to begin to pick up the pieces on this program? A full re-write is out of the question, and I don't think is needed.
I don't know that there is a "good" answer to this question, the only thing I can tell you is to take it one method at a time and document what they do as you figure them out. If you still have access to the people that initially wrote the program you can ask them if they could give you documentation on the system, but if that was not included as part of the original work spec I doubt they are going to have any.
I'm really learning so much, and one of the biggest things I'm learning about is proper commenting and scalability.
As you have found on your own, proper commenting is important, I'm not convinced on the importance of building scalability in from the beginning, going by the YAGNI principle. I think that as any program grows it is going to go through growing pains, whether that is scalability or functionality. Could someone have built twitter from the start with the kind of scalability in mind that it currently needs? Possibly, but there is the very real possibility that it would flop.
Is it common for a programmer to come into a project very far along and then "clean up" the mess in order to make things move forward productively?
It's definitely common for pretty much EVERY programmer :)
Having said that, remember the IIABTFI principle. If It Ain't Broke, Don't Fix It.
Understanding how the program works and what the pieces are is useful.
Trying to improve it without a specific goal and a business purpose in mind is not.
The big question is how well is the program currently running meeting the needs of those that use it? While it may not be the best looking code, it does work which may mean that you end up doing 101 refactoring exercises around it to get enough of the basics down to make other changes.
While you may be able to ask the original writers of the program, this can be a possible sore spot if they think it is awesome and you think it is crap, for example. It is an idea and one that should be carefully analyzed a bit before one goes and ends up burning bridges because they think you can't appreciate their genius in what was done.
Often this aren't done in an optimal way and so as one learns better ways to do things, things are done in better ways. There is a limit to that of course, but I'd start with the idea that you have some refactoring lessons to help get the basics of the app under your belt and then start putting in enhancements and other stuff to see what was really done in the end.
I have been tasked with supporting and maintaining several PHP/MySQL web apps (I use the term 'app' lossely) that seem to defy every known coding standard.
The PHP code contains routines, procedures, business logic, and even queries - it's all in the code. There is no object-orientated programming, not even MVC, and certainly no separation of the presentation layer from the application layer. No framework was used to build these apps either and I am using the Yii Framework for new projects.
Although it's time consuming should I rewrite these applications? At least half my week involves fixing them, doing updates are having to work with these existing apps in my new work.
Anyone have any advice on this?
An age old question that is asked alot.
When do you refactor code?
How do you refactor?
How do you stop yourself from refactoring working but awful code?
Basically, if it's working dont' break it. If you work in it, and can make changes to clean up the code without breaking it then do it. Rewrite code? I'd go with the idea of, What's the return of investment, how much time would it take, can you dodge the bugs of the old version without introducing new ones. Things like that.
Good luck with your project, and hope this helps.
I would caution against an all-out rewrite. If the application is working and has users, the path forward is to modify the existing codebase.
Yes, you can implement a framework into an existing framework-less codebase. It takes a lot of effort, but it is possible (I've done this several times). Starting over will cause you to lose precious time. That's been proven time and time again (remember Netscape?)
You're obviously smart enough to know that there is a problem, and to know that the solution is to improve the applications by implementing frameworks and clean them up. That puts you ahead of the game.
Implement new frameworks in phases. Start with an MVC framework - get it into the codebase, but don't fret about the fact that there is no separation of layers yet. Get a new version out that's built on top of an MVC framework but isn't truly obeying MVC conventions. It's a start. Then take a next step - move the business logic into the model layer. Or maybe leave it as it is, but make it OO.
Remember, your job is to produce a product that users can use. Your job is not to adhere to best practices. Meaning - yes, best practices ARE the correct course of action. But they don't matter squat if users can't use your app or your app can't compete with the competition. Don't lose sight of that. Work to improve the app so that you can turn it into a great product, but don't let perfection be the enemy of good.
In my experiences, this has typically been a business decision. Do your bosses know how much time you spend maintaining these systems? How many users actually use these systems? How critical are they to the business? Can you sell management on a rewrite and can you prove it will be useful and beneficial?
You can start some basic refactoring already in your day-to-day maintenance. Whenever you need to make updates, even if it might take a little extra time, find a way to work an OOP solution of some sort in, or clean up the code that's there to make it easier to handle. All-out rewrites are typically not a good idea and are a hard sell, but if you're already maintaining and adding in new functionality, there's no reason you can't use the new code or fixes to improve what's already there.
Will the products last for a long period of time? Will other users see the code and think that you did it? If yes to these, then you might as well rewrite the code. Try and get some support from your company and let them know the benefits and maybe you'll even get noticed for it.
While having no separation between the presentation layer and bussiness layer is clearly bad, there are some merits with other choices. If it is a pain to maintain code, just refactor the code as you go. Since you are familiar with good design patterns, you should be able do it fairly easily. Moreover, this will also help you reduce the bugs in your code. But remember that while refactoring code, things get worse before they get better. So, don't give up too soon.
I would suggest it depends on how much is the user load on these apps, do they really break apart in live scenarios and how much time are you wasting daily on these fixings and all.
Its always better to rewrite than break head on something which is totally messy.
I've got a big project written in PHP and Javascript. The problem is that it's become so big and unmaintainable that changing some little portion of the code will upset and probably break a whole lot of other portions.
I'm really bad at testing my own code (as a matter of fact, others point this out daily), which makes it even more difficult to maintain the project.
The project itself isn't that complicated or complex, it's more the way it's built that makes it complex: we don't have predefined rules or lists to follow when doing our testing. This often results in lots of bugs and unhappy customers.
We started discussing this at the office and came up with the idea of starting to use test driven development instead of the develop like hell and maybe test later (which almost always ends up being fix bugs all the time).
After that background, the things I need help with are the following:
How to implement a test
framework into an already existing
project? (3 years in the
making and counting)
What kind of frameworks are there
for testing? I figure I'll need one
framework for Javascript and
one for PHP.
Whats the best approach for testing
the graphical user interface?
I've never used Unit Testing before so this is really uncharted territory for me.
G'day,
Edit: I've just had a quick look through the first chapter of "The Art of Unit Testing" which is also available as a free PDF at the book's website. It'll give you a good overview of what you are trying to do with a unit test.
I'm assuming you're going to use an xUnit type framework. Some initial high-level thoughts are:
Edit: make sure that everyone is is agreement as to what constitutes a good unit test. I'd suggest using the above overview chapter as a good starting point and if needed take it from there. Imagine having people run off enthusiastically to create lots of unit tests while having a different understanding of what a "good" unit test. It'd be terrible for you to out in the future that 25% of your unit tests aren't useful, repeatable, reliable, etc., etc..
add tests to cover small chunks of code at a time. That is, don't create a single, monolithic task to add tests for the existing code base.
modify any existing processes to make sure new tests are added for any new code written. Make it a part of the review process of the code that unit tests must be provided for the new functionality.
extend any existing bugfix processes to make sure that new tests are created to show presence and prove the absence of the bug. N.B. Don't forget to rollback your candidate fix to introduce the bug again to verify that it is only that single patch that has corrected the problem and it is not being fixed by a combination of factors.
Edit: as you start to build up the number of your tests, start running them as nightly regression tests to check nothing has been broken by new functionality.
make a successful run of all existing tests and entry criterion for the review process of a candidate bugfix.
Edit: start keeping a catalogue of test types, i.e. test code fragments, to make the creation of new tests easier. No sense in reinventing the wheel all the time. The unit test(s) written to test opening a file in one part of the code base is/are going to be similar to the unit test(s) written to test code that opens a different file in a different part of the code base. Catalogue these to make them easy to find.
Edit: where you are only modifying a couple of methods for an existing class, create a test suite to hold the complete set of tests for the class. Then only add the individual tests for the methods you are modifying to this test suite. This uses xUnit termonology as I'm now assuming you'll be using an xUnit framework like PHPUnit.
use a standard convention for the naming of your test suites and tests, e.g. testSuite_classA which will then contain individual tests like test__test_function. For example, test_fopen_bad_name and test_fopen_bad_perms, etc. This helps minimise the noise when moving around the code base and looking at other people's tests. It also has then benefit of helping people when they come to name their tests in the first place by freeing up their mind to work on the more interesting stuff like the tests themselves.
Edit: i wouldn't use TDD at this stage. By definition, TDD will need all tests present before the changes are in place so you will have failing tests all over the place as you add new testSuites to cover classes that you are working on. Instead add the new testSuite and then add the individual tests as required so you don't get a lot of noise occurring in your test results for failing tests. And, as Yishai points out, adding the task of learning TDD at this point in time will really slow you down. Put learning TDD as a task to be done when you have some spare time. It's not that difficult.
as a corollary of this you'll need a tool to keep track of the those existing classes where the testSuite exists but where tests have not yet been written to cover the other member functions in the class. This way you can keep track of where your test coverage has holes. I'm talking at a high level here where you can generate a list of classes and specific member functions where no tests currently exist. A standard naming convention for the tests and testSuites will greatly help you here.
I'll add more points as I think of them.
HTH
You should get yourself a copy Working Effectively with Legacy Code. This will give you good guidance in how to introduce tests into code that is not written to be tested.
TDD is great, but you do need to start with just putting existing code under test to make sure that changes you make don't change existing required behavior while introducing changes.
However, introducing TDD now will slow you down a lot before you get back going, because retrofitting tests, even only in the area you are changing, is going to get complicated before it gets simple.
Just to add to the other excellent answers, I'd agree that going from 0% to 100% coverage in one go is unrealistic - but that you should definitely add unit tests every time you fix a bug.
You say that there are quite a lot of bugs and unhappy customers - I'd be very positive about incorporating strict TDD into the bugfixing process, which is much easier than implementing it overall. After all, if there really is a bug there that needs to be fixed, then creating a test that reproduces it serves various goals:
It's likely to be a minimal test case to demonstrate that there really is an issue
With confidence that the (currently failing) test highlights the reported problem, you'll know for sure if your changes have fixed it
It will forever stand as a regression test that will prevent this same issue recurring in future.
Introducing tests to an existing project is difficult and likely to be a long process, but doing them at the same time as fixing bugs is such an ideal time to do so (parallel to introducing tests gradually in a "normal" sense) that it would be a shame not to take that chance and make lemonade from your bug reports. :-)
From a planning perspective, I think you have three basic choices:
take a cycle to retrofit the code with unit tests
designate part of the team to retrofit the code with unit tests
introduce unit tests gradually as you work on the code
The first approach may well last a lot longer than you anticipate, and your visible productivity will take a hit. If you use it, you will need to get buy-in from all your stakeholders. However, you might use it to kickstart the process.
The problem with the second approach is that you create a distinction between coders and test writers. The coders will not feel any ownership for test maintenance. I think this approach is worth avoiding.
The third approach is the most organic, and it gets you into test-driven development from the get go. It may take some time for a useful body of unit tests to accumulate. The slow pace of test accumulation might actually be an advantage in that it gives you time to get good at writing tests.
All things considered, I think I'd opt for a modest sprint in the spirit of approach 1, followed by a commitment to approach 3.
For the general principles of unit testing I recommend the book xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros.
I've used PHPUnit with good results. PHPUnit, like other JUnit-derived projects, requires that code to be tested be organized into classes. If your project is not object-oriented, then you'll need to start refactoring non-procedural code into functions, and functions into classes.
I've not personally used a JavaScript framework, though I would image that these frameworks would also require that your code be structured into (at least) callable functions if not full-blown objects.
For testing GUI applications, you may benefit from using Selenium, though a checklist written by a programmer with good QA instincts might work just fine. I've found that using MediaWiki or your favorite Wiki engine is a good place to store checklists and related project documentation.
Implementing a framework is in most cases a complex task because you kinda start rebuilding your old code with some new solid framework parts. Those old parts must start to communicate with the framework. The old parts must receive some callbacks and returnstates, the old parts must then somehow point that out to the user and in fact you suddenly have 2 systems to test.
If you say that you application itself isn't that complex but it has become due to lack of testing it might be a better option to rebuild the application. Put some common frameworks like Zend to the test, gather your requirements, find out if the tested framework suits for the requirements and decide if it's usefull to start over.
I'm not very sure of unit testing, but NetBeans has a built-in unit testing suite.
If the code is really messy, it's possible that it will be very hard to do any unit testing. Only sufficiently loosely coupled and sufficiently well designed components can be unit tested easily. However, functional testing may be a lot easier to implement in your case. I would recommend taking a look at Selenium. With this framework, you will be able to test your GUI and the backend at the same time. However, most probably, it won't help you catch the bugs as well as you could with unit testing.
Maybe this list will help you and your mates to re-structure everything:
Use UML, to design and handle exceptions (http://en.wikipedia.org/wiki/Unified_Modeling_Language)
Use BPMS, to design your work-flow so you won't struggle (http://en.wikipedia.org/wiki/Business_process_management)
Get a list of php frameworks which also support javascript backends (e.g. Zend with jQuery)
Compare these frameworks and take the one, which matches the most to your project desgin and the coding structure used before
You should may be consider using things like ezComponents and Dtrace for debugging and testing
Do not be afraid of changes ;)
For GUI testing you may want to take a look at Selenium (as Ignas R pointed out already) OR you may wanna take a look at this tool as well: STIQ.
Best of luck!
In some cases, doing automatic testing may not be such a good idea, especially when the code base is dirty and PHP mixes it's behavior with Javascript.
It could be better to start with a simple checklist (with links, to make it faster) of the tests that should be done (manually) on the thing before each delivery.
When coding in a 3 years old minefield, better protect yourself with many error checking. The 15 minutes spent writing THE proper error message for each case will not be lost.
Use the bridging method: bridge ugly lengthy function fold() with a call to fnew() which is a wrapper around some clean classes, call both fold and fnew and compare result, log differences, throw the code into production and wait for your fishes. When doing this, always use one cycle for refactoring, anOTHER cycle for changing result (do not even fix bugs in old behavior, just bridge it).
I agree with KOHb, Selenium is a must !
Also have a look at PHPure,
Their software records the inputs and outputs from a working php website, and then automatically writes phpunit tests for functions that do not access external sources (db, files etc..).
It's not a 100% solution, but it's a great start
I've been a PHP developer for many years now, with many tools under my belt; tools that I've either developed myself, or free-to-use solutions that I have learned to trust.
I looked into CodeIgniter recently, and discovered that they have many classes and helper routines to aid with development, yet saw nothing in the examples that I couldn't do just as easily with my own tools. Simple things like DB abstractions, Email helpers, etc. There was some interesting code relating to routes - mapping urls to the right controllers; but even that's not particularly difficult to code yourself if you've ever written an MVC style web app with pretty urls.
Even after looking through some of the other popular frameworks, I still see nothing that would be that much of a time-saver. Even looking at the forums, I see people struggling to get the tools to work for them. I do understand how they would be more useful for junior developers, since full system design skills take a while to understand and appreciate fully.
Yet, I'm often told that I should use an off-the-shelf framework to produce my solutions, but I still remain unconvinced. What's the real benefit to someone like myself? Am I just being elitist, or is this a common opinion?
Edit: Looking at some of the answers here, should I perhaps consider packaging up my toolset as its very own framework, writing some documentation and posting tutorials? If I'm hesitant to take on other's frameworks, would opening it up and getting more eyes on it help to improve my own skills/tools?
Frameworks have several advantages:
You don't have to write everything. In your case, this is less of a help because you have your own framework which you have accumulated over the years.
Frameworks provide standardized and tested ways of doing things. The more users there are of a given framework, the more edge cases that have been encountered and coded for. Your own code may, or may not, be battle hardened in the same way.
Others can be recruited onto a project with a standard framework and have access to the documentation, examples and experience with that framework. Your own snippets may or may not be fully documented or have examples of use... but isn't much chance that others are comfortable with them initially.
EDIT:
With regards to your idea of packaging up your own framework, the benefit of cleaning it up for public consumption can be larger than the benefit of getting others to use it.
The reason is simple: you will have to re-evaluate your assumptions about each component, how they fit together and how clear each piece is to understand. Once you publish your framework, your success will be strongly dependent on how easy it is to get up and running with.
Big wins with little effort are essential for adoption (those wins will encourage people to delve further into the framework). Ruby on Rails in an example of a framework that gives such big wins with little effort, and then has hidden layers of features that would have overwhelmed someone just getting started. (The question of the quality of RoR apps is not the point, the point is about adoption speed).
After people adopt a framework, it is about the ease of continued use. Little details like consistent parameter use patterns make all the difference here. If one class has many parameters on every method, while another has setters that are expected to be called before invoking methods, you will lose users because they can't get a "feel" for what is expected in a given case without resorting to the documents.
If both ease-of-adoption and ease-of-living-with issues are addressed properly, you only have to get lucky for people to adopt your framework. If those issues are not addressed properly, even an initial interest in the framework will wane quickly. The reason is that there are many frameworks: you will need to stand out to gain the advantages of having others using your kit (as they rightfully are as wary of your framework as you are of others).
Here's another reason not to create your own framework. Linus' Law - "Given enough eyeballs, all bugs are shallow". In other words, the more people who use a given framework, the more solid and bug-free it is likely to be.
Have you seen how many web frameworks there are for Java? Back in the day, it was fashionable for any half-decent developer/architect to write their own custom web framework. And at the end of the day, 95% of them looked like a custom implementation of Struts (the most popular Java web framework at the time). So they basically created a Struts clone that was: 1) proprietary; and 2) not as well documented and tested.
Let's face it - writing our own customer framework is fun, but what happens next? It becomes a maintenance burden to keep up with the framework yourself (or the poor soul who replaces you). And maintaining software is much, much more costly, especially when it comes to custom frameworks. Is the company in business to solve domain problems or in the business of maintaining frameworks?
I forget who said it, but I once heard a great quote - "The first rule to creating your own framework is: don't". Somebody else has probably gone through the effort of doing so and probably done the same work you would have done. Save yourself the time, effort, and testing.
There's many comments here as to the advantages of using a framework, and certainly I think in a good many cases they are perfectly correct.
HOWEVER
All frameworks come with the downside that they have a domain of problems that can be fitted into them. If your problem is well inside the scope of the domain then using a framework isn't an issue, and most of the time it's readily apparent if your problem is well outside the domain so you don't give it a thought. Issues arise when you try to force a problem into a framework that it just doesn't quite fit into or has some unusual non-standard feature - in which case you complete 90% of the code really fast then spend all the time you've saved figuring out how to bend or extend the framework so it can accomplish some obscure requirement. Because in these case your solution/extension has to plug into the framework it can often be more difficult to code than if you'd come to it independently.
In the wrong circumstances this can actually be disastrous. For example if a client asks for a project that you believe will fit into a framework solution and you quote accordingly, then after completing 90% you find the gotcha then you can be really up the creek, especially if it's some feature that the client is insistent upon (and it always is). These issues tend to arise because it is not always apparent from the word go where the gotchas might lie, particularly if you're using a framework you are less familiar with (and you have to from time to time).
This is really the same problem as arises with deploying any third party software in a project. Myself from experience I have no qualms about using frameworks or similar, but given the choice I will always go for the lightest, thinnest, wrapper I can find that will do what I need. That way I gain the advantages, whilst knowing that if issues do arise (and they are generally less likely to with a thinner wrapper) then figuring out how to work around them is likely to be simpler than learning an extensive code-base to the point where I can safely modify it.
The framework code is likely to be well-tested and relatively free of bugs. By using it you save yourself time testing/maintaining your own code to do the same thing.
And any time saved is good. Laziness pays off in programming.
One thing that you will be missing out on is all of the Validation that goes into a popular framework.
Your routines simply don't have the same exposure that the popular libraries have.
You may have a point.... however I wouldn't underestimate the power of many, as an example phpBB is as far as i'm concerned the bb solution to use. Why? Because there are many, many thousands of posts on their support boards and many people using it who are knowledgeable and can help people solve problems.
Therefore the only reason in your case to use a popular framework is the many others that use it, report bugs against it, fix it and support it. It'll be tricky to get the same coverage on your own libraries.
I would go against the grain here, and say, you should use your own custom framework, If the software you are building is the core of your business. As Joel would say, "Find the dependencies - and eliminate them". If you are just putting up a little website for your company, and you business isn't maintaining websites, then go ahead and use a framework. But when that website is your business, then you shouldn't depend on a framework from somebody else to let you get the job done.
I think the main reason is that when you use a common framework, there are a lot of people who are instantly familiar with your product.
Apart from that I think it's most important that whatever tools you use actually get the job done. If it happens to be familiar to other people, then that's a bonus.
I agree you should use your own custom framework. Not only is it easier for you to understand, but it provides the ultimate in job security!
Three reasons I can think of immediately:
A well-known framework will be familiar to other developers who may have to work on your project
A well-known framework will have resources like books, discussion boards, and other experts that can be used for finding out more information
Managers will often have a "don't reinvent the wheel" philosophy. In fact, existing solutions have probably solved the same problems that you'd discover if you create your own solution.
All of that said, there may still be a place for your own solutions. We wouldn't have so many frameworks (or scripting languages) to choose from if no one started something new.
Any experienced developer can build a framework -- the challenging part is convincing others that it's worth using. You'll need to create documentation and tutorials for it for those who plan to use or maintain it. You'll probably need to create a demo site to prove that its useful and actually works like it's supposed to.
That alone can be a considerable investment, not including bugs that could pop up in between. When its all said it done, it could be worth spending time learning another framework instead of making your own.
You mentioned CodeIgniter -- I personally feel like that's a pretty framework -- it doesn't get much more barebones than that.
What you essentially have is your own framework. So, it isn't a time-saver FOR YOU, because you have already spent the time to develop the framework. If you didn't have that to build from, it would certainly be easier and faster to use an existing framework than to roll your own.
What you need to look at is whether or not your framework is better than other options out there, and whether your familiarity with your own code outweighs having other eyes looking at it, and other people using it in enough different ways that the likelihood of any problems being found and corrected is much higher.
Also, if your framework is so much better than everyone elses', you might consider opening yours up to the community ;)
As you probably know: "time is money". So by using a popular framework with a lot of helpers, a lot of code examples on web and a big community you do more in less time.
Sometimes it if ok to use frameworks because you become more productive, but in some advanced and difficult projects it may happen so that the framework stays in your way and you have to find workarounds.
I think there is no definitive answer. You should put in balance the pros and cons and take the right decision for your project.
Usually I adopt popular frameworks very fast but not in critical parts of the projects and in time I extend their usage.
I think that if you don't see a need to use a framework then don't.
The reason I use a framework for example Django for python or Rails for Ruby or Webforms and MVC for ASP.net is because they make it easier and faster to write applications for them. In the case of Ruby and Python not using a framework for me would make me go crazy.
If you have something that works and don't see a need to use a framework I would say stick with what you feel is best. But, I would still keep up to date with frameworks.
I think they are more useful if you are starting from scratch and don't have the time to write your own. If you already have a codebase you developed over the years, they may be much less useful, but it may still be useful to take a look and see what they did.
For example, I am sure major game development shops are not using third-party tools, engines and frameworks, not because they are not sufficient, but they already have built their own since the 80's or whatever.
Plus, if you are using an off-the-shelf component, there is no way to exceed it in its particular area. If you need to be a market leader in a particular dimension, you should be building your own solution in that dimension, so you can lead. If you don't need this capability, using a third-party component that is just as good as yours may be a good solution as long as it is an easy transition. Time to train in the new tool and living with its idiosyncrasies may or may not be worth it though.
The other thing to consider is that if you can build something, you truly understand it. Otherwise, you don't. Now, you don't need to fully understand stuff to use them, so long as they "just work", but we all know how that goes... :)
Can you solve the problems you are given have with your code faster and more reliably than public frameworks?
If yes, then keep using your own.
If no, then find the framework that does a better job and run with it for that project.
It all comes down to which codebase gets the job done better(for the value of better given by the client. ;) )
Disadvantages.
Most frame works are not object orientated. (code igniter does show some promiss)
Most of the code is done via includes. trying to track down the problem is like pulling on a thread on a sweater, and having to unravel the entire garment to fully understand the creation.
Most frame works have poorly written documentation.
Most frame works try to do many many many things.
I find from my experience developing with frame works that it takes a good 3-6 months to get on top of the code base. And its only after that period of time that you will find out weather you are trying to fit a square peg into a round hole. Given that most php projects want to be finished before that period has elapsed, it will cost employers more to get any project using a big "frame work" to fruition.
Many of the php Frame works were written for php 4, and were written in a different enviroment. They have been extended greatly, but are showing their origins. The use of global constraints is particularly prevalent. I am hoping that php 6 puts most of them to death. Code igniter escapes most of this, but it is new, and has object orientated parts.
Some frame works have written code that is not needed, and causes problems.. eg: CAKE has a most excellent model view controller, but its session handling is a disaster. Unfortunately frame works are not written in a modular way. Often its an all or nothing option.
MOst programers "hack" the frame work to get it to do what they want. This leaves future programers sractching their heads. It also makes "upgrading" the frame work a impossibility.
I have yet to see a frame work that implements unit testing. (how do you know that you have not broken it).
give me a well written object any time. At least them you know the scope right off the bat.
Advantages are that it's already written and tested by multiple people therefore less likely to be bug prone.
Disadvantages are that it's not built specifically for your application and therefore will most likely perform worse.
All in all, I can't really see much reason to use one considering you already have your own...although it may be worth releasing that open source so others are able to bug check and recommend improvements.