Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

At our company, we have a custom software application using our own framework. The framework was built in approximately 2002 or 2003, long before I showed up at the company. Majority of the functions in the framework are solid so we still use them as we've never had any issues with them, I'm talking about the database functions and functions to grab get/post parameters and escape data, etc.

It used to be just me working on the projects so I never had any issues with the code-base, however we now have up to 6 developers who started working on the framework recently so things have become more complicated. In our current framework have it set up such as:

/cms/
/cms/modules/
/cms/modules/filemanager/
/cms/modules/filemanager/index.php
/cms/modules/pages/
/cms/modules/pages/index.php
/cms/...

Now inside each index file of each module we have the following:

require_once '../../config.php';
require_once '../../database_functions.php';
require_once '../../url_functions.php';

I am finding it more and more difficult to maintain the changes now and now that certain modules are interacting with other modules it is just getting crazy to maintain this among all of our development team.

It used to be very simple but now our page module actually integrates other modules into the main module, into placeholders basically so one can put any content from individual modules into the page.

The issue comes when we make a change to our gallery module and now I need to make changes on the front-end (html output), the gallery module itself, the database and then debug all the errors that come about in other modules that are currently using the data from the gallery module. It becomes a chain reaction of changes basically.

Does anyone have any suggestions of how to streamline things or a better way to control the maintenance of our application? We are still using a very structured way of coding using straight scripting and functions rather than OOP, as I am used to coding in C and I don't like to complicate anything more than necessary.


Aside from these issues, we don't use anything like versions in our software right now, we've distributed great work and clients love the software we give out, we just don't have versions on them and no builds or anything, which is probably a big mistake in itself.

Any ideas or suggestions or even a link out to somewhere that can help us figure out how to better structure our development process (if that's an issue) would be greatly appreciated.

share|improve this question

2 Answers 2

up vote 0 down vote accepted

I'm going to answer in a general way, not addressing any PHP specific issues. The root of the problem is that your team has grown from 1 developer to 6 developers. As each new developer approaches the code base, s/he will see ways to innovate with the code and to use the structure in ways you didn't anticipate. Also - without a build and version control system, multiple developer committing simultaneous changes can lead to chaos. Here are the steps I recommend:

  1. Approach solving this problem as a team. Everyone should be aware of the problem, and should participate in integrating best practices into the development process. The team, as a whole, should agree on what will be the ongoing release, build and test process.

  2. Agree on the release process, so that people are not stepping on each other's changes. This means defining a release, version tagging code, and branching as needed.

  3. Start building automated unit/regression tests that developers run before each check in. This allows each developer to record his/her assumptions about the code, and will alert other developers if they break those assumptions. There are many good web test frameworks out there. Pick one and start using it.

I'm assuming that at least some of those 5 other developers have experience working in a team environment, and will already have some suggestions about how to move ahead.

share|improve this answer
    
Thanks very much for your advice here. I've never dealt with a real team environment before which is a huge problem. I will see about getting everyone together to develop a standard process for building/testing/deploying code, etc. We have never used any sort of testing framework either, very much "spaghetti", we make modifications when we need and directly to live code most of the time. –  jnker May 17 '12 at 20:09
    
I've been hunting for a framework that isn't based on objects as we don't currently use OOP methods, however I realized I can just be writing our tests in PHP itself to test out our functions, will give this a try. –  jnker May 17 '12 at 20:20
    
@jnker: You might want to try Selenium. Although it isn't testing at the coding level (like PHPUnit would), it would give you an easy way to create regression tests for your web app, to run after each build. Then again, maybe you could use PHPUnit even if you don't use OOP methods. –  Sam Goldberg May 18 '12 at 20:25

First off, you claim that your legacy 'core' libraries are solid. My stance on that would be to isolate them from the dev team. Embrace just a little bit of OOP by wrapping them in extended purpose built wrappers. So if you need the db code for filemanager, write a dbfilemanager intermediary so that you can change it and not mess up 'pages'. likewise add a dbpages for the same reason.

The 'good practice' is to not mess with robust, well-aged code and to simply extend it for specific purposes.

I personally do not mind if code is duplicated in the universe, particularly if it enables legibility and cohesiveness in a system's design. In other words, even if you have a mostly similar function in DBFileManager and DBPages, at least your code paths don’t have cross-dependencies. You're code sounds like it is rapidly becoming spaghetti as subsystem-specific features are pushed into core libraries. You'll be happier the sooner you stop doing that.

Regarding versions, they are just labels to help you identify the most likely culprit when something is not working. Versions also can make people think they need to buy the latest because their version number is so old. Both reasons are very good and should be used to convince your company to start using them.

share|improve this answer
    
Thanks very much for your response. That is definitely what happened. When someone wants to modify the way something "core" is working they go direct to the main function which is just horrendous as they have no idea the impact it will have on any other script using the function. So I should really be able to have a base function in a wrapper...and if someone needs the functionality to be slightly different they could overwrite it by extending the original class and overriding the function, thus not breaking the rest of the scripts, am I correct? –  jnker May 17 '12 at 20:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.