4

I've got to dive into a very large PHP site and have my first client meeting today. All they gave me so far was the URL.

How do you guys go about gathering/structuring/documenting and preparing for a new project in a PHP environment? What things do you ask for up front?

PS - I know there are other general questions about this but I want a PHP-flavored one, including tools (even if universal) and approaches.

Thanks!! I'm excited but also scared.

Improve this question
2
  • if it's with a client, why does anything need to be PHP-specific? Commented May 6, 2011 at 15:23
  • This is the pre-meeting. All I have so far is the URL ;) I'm trying to plan ahead!! Don't hurt me for that! Commented May 6, 2011 at 16:54

5 Answers 5

Reset to default
1

I asked this same question recently. I'd like to answer with my input now with a month and a half in.

Here's the original question: "Whats your approach to assuming someone else's project?

  1. Read the documentation, if there is any. If you're lucky, you should be able to gain some insight into the project's functions and nuances. The code in my case (by the way, this is a 15000 file site) is fairly well documented, but there's still some quirks about it.
  2. Setup your debugging environment. Whatever flavor that may be. Set breakpoints and trace through the code and see what is expected. This has been critical to me - most errors I can find through the error message, but others I get kind of lost in. That's where the debugging comes through.
  3. Try something for the sake of learning. Add a new version of jQuery. Create a test form. Do something outside of the task list so you can get comfortable with the methods and architecture.
  4. Make sure you're covered in the event that something goes wrong via code. Assume that a failure could cause an impact to mission-critical processes. In your code-infancy, you may not know how to fix it immediately. At the very least, use versioning software so you can get everything back to its running state as quickly as possible.
  5. If you can, get your own personal playground where you can do whatever you want. Destroy that class - streamline those includes. Just somewhere you can independently explore. It is very important that you get your hands on the code and work with it.

I hope this helps. I'm still in the process of taking over my project and at times it can be tough. But, challenges make the day go by faster.

Improve this answer
0

As far as getting the original code structure - you could start by running PhpDocumentor over the codebase. Even if they haven't used docblock syntax, this should at least map out functions and classes and present it in a reasonable format.

Improve this answer
0

A black-box review of the website's functionality should give you some clues as to how it is built. Clearly, such a review will not give you any explicit information about how the source code is structured, but you should be able to map out on a page-by-page basis what everything does (i.e.: CRUD operations).

The black box review is also helpful because it will allow you to get a sense of what works currently and what does not (from both a technological and usability perspective), which you can then turn into constructive feedback if/when asked.

That should be enough to get you started and get you through the meeting.

Improve this answer
0

In your meeting you had to listen carefully what your client says. Important to know is anything he emphasizes.

After that, when you're in front of the code, get the list of files involved, and try to figure out what is code made specially for the app and what is external code (libraries for example).

Anything you learn should not only be written down in paper, but also put graphically with a diagram. In the beginning just a flow chart will be useful. Let more structured UML diagrams for a second and more in-depth review.

It will be discouraging at first time, and may be also very difficult if the code is poorly written, but bear always in mind that what you are doing is possible and will be achieved at last.

Improve this answer
4
  • I like the positive outlook at the end for the "grunt" work. Commented May 20, 2011 at 3:30
  • I appreciate the life cycle stuff, but I'm cool with that. I was looking more for particularly useful diagrams or software that would break things down with dependencies. I've been using PowerGrep and Visio and GraphViz to do some hacky stuff. Commented May 20, 2011 at 4:57
  • A very useful type of diagram for business process modelling is EPC. It is useful because it embraces the business login and also gives you insight on the modules a system has or may have. Commented May 20, 2011 at 5:00
  • And for diagramming I find yEd extremely powerful. And it is also freely available. Commented May 20, 2011 at 5:02
0

Last year I took over as the developer of a PHP/MySQL web application with around 350 PHP files and 50 SQL tables. The original author had no prior programming experience. Despite this, the database organisation fairly well normalised, but basically every decision taken after that was sub-optimal. Dates stored as "DD/MM/YY" strings, for example (parts of the app are heavily time-dependant), and an RPC-based API where all input was unsanitised and database changes (CRUD) were allowed via GET calls, accessed via <a> links! I am amazed a robot hasn't indexed all the delete*.php?id= pages :)

After nine months of code clean-up, adding new features, repairing old ones, SQL optimisation, database sanitisation, URL re-writing, and migrating the API to REST (still not complete), the code is now in a position where I would be proud to let others see it.

I intend this answer as a sort of case-study summary. Basically 1 developer, 350 PHP files, 50 tables, took 9 months. Hope that can help you, or any who follow, in gauging how long such a project may take.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.