PHP Team Development: Easy and effective team work using MVC, agile development, source control, testing, bug tracking, and more

The rationale for the use of patterns is very simple. We face problems when we develop software. We might face problems on making decisions about which algorithms to use, what is the most suitable design, what techniques to use, and what modules to use. The chances that the same kind of problem has been encountered by some other software professionals are very high. If someone else has faced the same problem before us, the chances of them having solved the problem is very high. If someone already solved the kind of problem that we are trying to solve, we are better off learning from that solution which is already available, rather than trying to reinvent the wheel.

Every problem is unique. Therefore, every solution should also be unique. So how can we use someone else's solution to our problem? The rationale for the use of software patterns is not about picking up ready made solutions to problems. Rather, the patterns guide us on how to approach a problem. In the...

MVC is a widely known pattern that guides us to separate the presentation, logic, and data in an application where there is a user interface involved.

In the previous chapter, we discussed how separation of concerns would help when working with a team. We can divide the system into separate parts with independent concerns and get sub-teams to work on each separate aspect in parallel, and integrate all those individual pieces of the puzzle at a later stage.

The preceding image shows how we can distribute our team to map the elements of MVC. Team members can be assigned to each layer, based on each person's expertise.

The MVC pattern helps us identify key layers of a system with ease. At the highest layer, we can divide the system into MVC and get the sub-teams to work on each aspect.

The simplest assignment is to assign each layer to a sub-team. Thus, presentation, business logic, and database layers will each be handled by a separate sub-team. You can have UI experts assigned to the presentation layer, database experts to the data layer, and those who have a good understanding with algorithms and who have a good...

You will run in to integration challenges, first and foremost, if you did not adhere to the principles in the design pattern. The simplest thing to remember is not to cross boundaries and that is the basic idea of the separation of concerns.

Always make sure that the team members of your team consciously ask the question, 'Is this within my boundary?'. The idea is to not pass the balls across to the others, but to stick to good design norms. The idea is pretty simple. The presentation should never process data, but only present information to the user.

Today's powerful web browsers can do so much that we might tend to lose focus on boundaries. For example, the presentation layer can use AJAX and naturally tends to do some business logic...

In this chapter, we had a look at how we can use the MVC pattern as the basis for separating concerns in the application and assign team members to each layer.

The presentation layer, or the view, is the layer that is most likely to change over time. The business logic layer can also change over time, but not as frequently as the presentation layer. Separating concerns helps us deal with system changes, as the system evolves.

When assigning team members to each layer, and each aspect within a layer, you need to take the personal skills and preferences into account, to ensure team success.

Adhering to the MVC principles will ensure that we can achieve system integration without any major surprises. As long as the model, view, or controller implementations do not cross their boundaries, we can ensure that we have loose coupling in the system, and therefore ensure that we can put them together to get the whole system working seamlessly.

In the next chapter, we will further dive into team...