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

Therefore, you need some discipline, and a process. You need to learn how to work in parallel with others on different aspects of the same project. The parts from different developers will be integrated together at some point in time, and once integrated, they need to work seamlessly. Having said that, the PHP project team—that works on the PHP project for an organization—can also benefit from the luxury of the PHP language, being powerful and flexible. Therefore, you do not need a rigorous process either.

So where is the fine balance? Many software professionals now turn to agile processes. PHP teams can greatly benefit from an agile process, because PHP can help you live with agile values.

The agile process focuses on the agility of the team and the team working on the project focuses more on the delivery of a quality project, rather than getting stuck in a rigorous process. Rather than focusing on following the process, the agile principles focus on getting things done and getting them delivered to the client.

It is evident from the previously stated agile values that we are more focused on making customers happy by trying to deliver what the customers want.

Two minds are better than one. The whole is greater than the sum. You need a team because the problem at hand is difficult. However, you need to be organized and have discipline in the team in order to be successful. The best way to attack a complex problem is to break it down, into separate manageable parts.

When the problem is broken down, each sub problem could be solved in order to solve the whole problem. In the break down phase, it is a good practice to adhere to separation of concerns principle. For example, the user interface deals with presenting the application to the user. Based on inputs provided with the user interface, you carry out the business logic processing. For example, let's say that there is an application to help users query for the values of different stocks. The presentation would let the user enter a stock symbol. Once the user submits the form, the stock symbol would be sent to the backend, and the business logic would try and locate the quote for the given symbol. There isn't much business processing in here, just a query. However, in the next step of the application, the user might want to buy some stocks. At the presentation layer, the user will specify the symbol, and the quantity that he or she wishes to buy. When this request is submitted, the business logic layer would extract the stock price for the given symbol from the data layer, multiply that by the number of stocks that the user wants to buy, and provide that to the presentation layer. The presentation layer would display the total value to the user.

Here, presentation and business logics are separate concerns. The Business Logic Layer can also be broken into computations and retrieving and storing to persisted data storage. Computation is a separate concern compared to data storage. As an example, retrieving the price for a given stock symbol from the database is one aspect and computing the total cost using the price and the number of stocks is another.

Once the problem is broken down based on separate concerns, you can get different members of the team to work on different aspects of the application.

In a single PHP script, all aspects, such as presentation, computation, and data retrieval, could be done very easily. You can present a form to the user, get input, connect to the DB, retrieve relevant data based in input values, do the computation, and send the result back. However, that is something a novice programmer would do. An experienced programmer would use the MVC (Model View Controller) pattern. Patterns are proven solutions to well known problems. The rationale is that, the kind of problems that we are trying to solve when implementing a system, must have been seen by other developers in the history of computing, and they must also have solved those. Therefore, rather than trying to reinvent the wheel, we can benefit from the kind of solutions that has been used.

If the system is complex, using patterns alone would not help. This is because there are a few aspects that you need to address.

Earlier, we discussed the divide and conquer approach for a complex solution, and stressed the need for separation of concerns. When separating concerns, you can either divide it horizontally or vertically. An example of dividing horizontally would be to address the presentation layer by one team, business logic by another team, and database layer by yet another team.

Dividing vertically would mean to separate the system logically based on various functionality. For example, listing the products, purchasing a selected product, and product delivery related tasks could be handled by different sub-teams. The sub-team would handle all of the functionalities in the completion; meaning presentation, business logic, as well as data persistence, for each functionality would be entirely handled by the respective sub-team.

Whatever the separation style, the cross-cutting concerns come into play. Cross-cutting concerns are those aspects of the system that has system wide impact. One important example is logging. We need to use a consistent approach, especially in the format of log messages, throughout the system. Another important example is authentication. We have to be consistent with respect to authentication throughout the system. We are not supposed to use different authentication mechanisms for the same system. If we do, there are chances that we might leave behind some security holes in the systems. We might have to verify all different authentication mechanisms into the system. If we leave behind even one authentication mechanism by mistake, that would open up a possible back door into the system—risking the security of the entire system. Therefore, authentication needs to be handled in a consistent manner throughout the system. Therefore, we are better off providing a single, unified authentication library for the entire system. And one sub-team should work on that aspect. This would not only ensure consistency, but would also ensure enhanced reuse. Reuse will be enhanced because one interface would be used by all other modules in the system for authentication. In addition, this approach of addressing cross-cutting concerns by a given sub-team eases integration pains. If each sub-system used its own security module for authentication, then when all of those sub-parts are put together, in other words integrated, there would be numerous integration pains.

For example, if one module did not take all aspects into account while authenticating a user, that might open up a security hole in the overall system. If there was one module to address security, you can fix it and the improvement would be reflected across the entire system. Fixing each module would be really painful. The approach where cross-cutting concerns such as security are separated prevents regression issues. If the security module is broken, it is obvious where to fix it.

Consistency also applies to the presentation layer. Often, we use a common template to guarantee a consistent look and feel. A template helps us to define the common subset of the web pages in our presentation layer. When the data gets updated, we just need to fill in the placeholders with those data into the template. This way, we do not have to worry about the entire page all of the time. In addition, we need to have consistency across all web pages in a unified system. We can use a common template to achieve this, and when we want to update the look and feel of the entire web site, we just need to change the template and the entire site would get updated. This way, we can save time and energy spent on changing hundreds of pages. It is a common practice for developers to use tools or a library to help with the template. This is due to the benefits such as consistent API, specific feature sets, and recognizable template markup across the project that the template engines provide us. This way, system maintenance and management becomes very easy. But that does not mean that we do not need to pay attention to consistency when developing content to be embedded into the templates.

Even the content that is to be embedded could have layout concerns. For example, where in the page the content will be placed and how the content will be presented. The content that fills in the main templates would come from modules, which again are in the form of smaller templates. But when we choose the layout and the formation of the content within those, we need to ensure consistency. For example, if the data is presented as a list of bullets, would that fit into the rest of the larger template layout? Should that content be a set of links? After all, the entire page that the user sees is a single web page formed using multiple sub parts.

Therefore, in practice, it is easier to have the entire system broken in terms of horizontal concerns, to achieve team success. It makes it easy to deal with changes. On one hand, there are people who know the domain, and on the other hand, we can easily identify the areas to be changed and also easily pin point the problem location if we happen to run into bugs.

Bugs are inevitable, and a complex system will have bugs. The success criterion is how fast we can locate those bugs in order to fix them. In my experience, it is not bug fixing that takes time, but rather locating the bugs in terms of understanding where and why things are going wrong.

We can try and reduce the number of bugs through the process. However, changes in design and implementation would always lead to bugs.

Continuous integration helps when it comes to easing integration pains. In the context of a PHP project, continuous integration means that, rather than trying to deploy only those scripts that one or few developers implement on a developer's machine, all useable libraries and PHP code developed so far, needs to be put together by all developers in their local machines and test their own bits and pieces. Alternatively, all of the team members can use a staging server onto which they deploy all of the PHP code that they develop, at least on a daily basis, and run the tests on that staging server. This ensures that all individual pieces are integrated together on a regular basis.

If separate sub-teams of the team keep on working on the independent aspects for too long, then the chances of surprises when the system is integrated is higher. It is a good practice to integrate on a daily basis. This will make the overall system break too often, but at the same time, you can solve the problems early. As mentioned earlier, a common staging server can be used by the team for daily testing. It is a bad idea to use the live site for this kind of testing. This model saves time over time. For example, the presentation layer, that is the web page, might have assumed an older interface on the back end. The business logic library implementers added another parameter to the method being invoked. For the front end, this might mean an additional element in the inputs form, and these kinds of changes are accumulated over time. For a project where development is very active, this may mean a drastic change—even within a week. The back-end folks might have made assumptions too, about the front end, when they implemented their code, so those need to be fixed earlier in the development cycle as well.

These sorts of drastic changes and lack of understanding would prevail in the early stages of a project. The developers in the team would be learning what is required by users and also how to design the system. Therefore, a prototyping model would help a great deal in here, where the team develops something for the sole purpose of understanding the system and get over the assumptions.

Obviously, continuous integration requires aggressive code sharing. Therefore, you must seek help from a code sharing system, for example, Subversion (SVN). SVN is a source code revisioning system that can be used to keep track of the differences in the source code, but it also can act as a source code repository. So in addition to comparing differences between your local changes and the latest code in the central code repository, you can also make use of SVN to merge your changes to the central repository, so that you share your local changes with the others. This way, it becomes a source code sharing system.

You also need unit tests to verify and guard against regression. As it was mentioned earlier, unit testing helps us guard against regression issues. We need all developers working on the project to write their own unit tests that test each area that they develop in isolation. Once we have those unit tests, life becomes easy to test the system when upgrading and changing the system. Unit tests can be automated, so that the developers need not worry about running the test framework manually. To make sure that unit tests are really run, we can integrate those to the staging server update process. This ensures that whenever a developer adds something to the staging server, the entire unit testing framework is run. If anything is broken, a notification could be triggered.

All of this needs to be controlled carefully. Therefore, you need the application of software engineering principles. When we talk about integration, there are numerous practices that we can learn from the software engineering principles. Defining a process for change control, techniques to be followed when implementing testing, and quality assurance practices are some examples where established software engineering principles can help us.

Patterns can help make the software more robust and capable of dealing with change.

For many PHP applications, MVC is the most useful pattern. This is because PHP is used for web-based applications. However, they are not just web pages, but are applications based on backend business logic. There are numerous other patterns such as observer/observable, iterator/for each, and handler chain, which can be of use in the design of the system.

Applying a pattern just saves time and effort. We need to be aware of the problems and solutions that the patterns try to address in general, to make use of patterns effectively. A pattern is a description of a problem and the potential solution to it. There is no standard answer for all problems that we find when working on a software project. So it helps to be aware of the problems, and be capable of adapting the solution suggested by the pattern to suite the problem at hand. Many software professionals have used patterns over the years and the patterns are proven to work. You might have used patterns without knowing that it is a pattern, but not knowing the principles would lead to creative chaos. It is always advisable to spend some time and learn the principles behind the software patterns for any developer. Having the knowledge about problems that can appear, and the potential solutions to those problems, adds to the experience of a good PHP developer. The effort spent on understanding the patters would help the PHP team members in the long run. It would even be a good idea to train the entire team on patterns with hands-on examples in the early stages of a project.

Many frameworks or tools support patterns out of the box. All that is required is to apply the pattern carefully to your application. It is also important to make sure that everyone in the team understands the pattern, as well as how the pattern applies to the problem at hand.

A process helps people to streamline what everyone is doing to make sure a successful product, in our case the software, is built. As mentioned earlier, given that PHP is simple, people tend to overlook the need for a process in PHP-based software projects. A process that defines the set of activities, the ordering of those activities, input and outputs of those activities, and is followed in a given sequence, produces the right outcomes. For example, we need to analyze the system, design it, implement it, test it, and deploy the system into production, followed by maintenance.

Complex software needs some process in place. It is not required to be too religious about the process. However, you need to pick and choose the right process for you and make sure that all members of the team on board follow the process as expected.

Today, many people follow an agile process, or agile-like processes. The focus of an agile process is to make sure that we effectively deal with change and deliver the product sooner. Earlier in the chapter, the agile principles were introduced.

The values of the process focus on getting things done sooner and in an easy to turn around manner.

Source code revisions should be maintained so you can revert to an old code if necessary. Source code control is a must. It is especially helpful in situations where you are troubleshooting to locate the cause of an issue. If you know a broken feature was working some time back, you always can revert back to a known point and try to locate the change in code that caused the problems.

Source control also helps to keep in touch with what others are doing to the code by having a look at the change summaries. Most source code control systems support a means of evaluating the difference between the central source code repository and the local copy that a developer has, that he or she might have changed. With SVN, all that you need to do is to run the following command:

svn diff

When you work in a team, collective code ownership is a must. The commands such as svn diff make your life easy when living in a world where the source code is shared.

There are various source code controlling tools around. For example, SVN (http://subversion.tigris.org/) and GIT (http://git-scm.com/) are the most popular source code controlling tools nowadays. We will visit source control tools, and more importantly best practices, later in this book.

The concept of revisions, as shown in the preceding screenshot, helps to keep track of the changes that each developer in the team has done on the PHP source code. Whenever a change is done and is integrated with the central source code repository, it will be identified by a unique revision number. Revision numbers given to changes are continuous, and that helps to figure out the exact sequence of changes that has gone into the source code between two points in time. This makes it much easier to pinpoint problem causing changes, from among a sequence of changes that has taken place on the source code.

Make sure that everyone builds the system regularly, at least once a day. If the system is too large, make nightly builds. A build is a package where everyone's changes to the source code are included, and all of the elements of the software system are present. When the developers are busy with their own sub-modules, PHP classes, interfaces and unit testing the sub-modules, it can be easily overlooked to put all pieces of the system together and give it a test run.

For PHP, there is no compilation involved. There are cases where packages can be compiled and packaged in PHP, which correlates to something similar to building. For example, when developing PEAR packages and creating automated documentation, you would build the system. So what does it really mean to say 'do continuous builds?' Why bother with builds at all when working with PHP? There are numerous use cases in which continuous builds come into play. For example, those who are working on the database might change the database configuration or data schema. People who are working on libraries might refactor their code and change script paths or method signatures. This is possible, because everyone is busy developing in parallel. For maximum utilization of team resources, especially people, as well as to deliver the system sooner, you need to work in parallel. There is a drastic difference between working in parallel and deploying in parallel. When delivering a system, we need to define a set of milestones that we want to achieve as the project progresses. Each milestone would be achieved with a series of work iterations. Before deploying to the live system, for the purpose of integration testing, we would need to deploy the milestones to a staging server. Continuous builds are meant for testing with staging deployments and not for the real-life deployment of an application.

Due to the dynamic nature of the project and the way the team members' work, when you put all of the pieces together, the final picture would look drastically different from what you would see in isolation. You need to make sure that everyone sees the big picture on a regular basis.

When you are working with a team of people, there are various sub-groups within the team, who are experts in various domains. Some are designers and developers. Some are user interface design experts. Some are experts in testing and quality assurance. When you are working in a project, you need to keep all of these team members posted about the latest status. The designers, developers, and UI designers need to know what progress has been made so far. You also need to give the latest picture to the quality assurance (QA) team on a regular basis. In traditional software engineering, the quality assurance team would wait until they are given a release pack or a QA build. But with agile process, you can make the QA team be part of the daily process, helping to find issues on a daily basis. Continuous integration eliminates big surprises in terms of integration efforts.

Talking about QA, keeping track of issues in the system is very important. It makes life easier when you know what issues were found, what issues are still open, what were fixed, and when those were fixed. Sometimes, due to regression, some issues might even get reopened.

You can assign issues to team members and schedule issues so that other stakeholders of the project get to know when the issues will be attended to.

Not only bugs, but also improvements, wish lists, tasks, and so on can be tracked with an issue tracking system. This makes sure that all good ideas are noted and attended to at some point in time.

There are numerous tools that are available, both open source and commercial for bug tracking. Jira (http://www.atlassian.com/software/jira/) and Bugzilla (http://www.bugzilla.org/) are two popular bug tracking tools.

Communication is a critical factor for the success of a software project team. No matter how technically competent your team members are, if the communication is not perfect, the entire team could fail.

If the interface between presentation and business logic layers are to be changed, then all of the members of both the presentation and business logic sub-teams should know about the change. It is not only the fact that the interface is going to change that needs to be communicated, but also the rationale for the change, who gets affected, what to expect, and what needs to be done by each member to make the change successful.

There are many forms of communication, and there are many tools to help you with communication. You can have face to face meetings and design and code review sessions. Wikis for documenting and noting down discussion points, are shown in the following screenshot:

Mailing lists and forums can be used for discussions. Likewise, chat rooms can be used for discussions. However, discussing in a chat room is very different from discussing in a forum or mailing list. A chat room is real time (synchronous), whereas a mailing list or a forum has a time lag involved (asynchronous). Unlike in a chat room, you need to wait until the others respond to the emails or the forum entry. On the other hand, mailing lists and forums are archived (as shown in the following screenshot), so they can be used as informal documentation as well. Instant messaging is another great channel that can be used for communication. Instant messaging also comes with great archiving facilities.

Various forms of communication can be used for various communication needs of the team. It is helpful to ensure that every team member understands the need for communication as well as the means of communication to use, based on the information being communicated.

We will discuss the tools and techniques for communication, in detail, later in the book.