PHP Team Development

By Samisa Abeysinghe
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
About this book

Given the nature of the business environment today, organizations that want to build value-added enterprise PHP applications need a team of PHP people rather than an individual. You've got a team! What next? Customizing such applications to meet with organizational objectives and maintaining these applications over time can be quite a tedious task for your team with so many people involved.

In this book, you will explore how you can break up complex PHP projects into simple sub-parts that multiple team members can work on. The book highlights the use of the MVC pattern for separating concerns in the application and agile principles to deliver code that works. You will learn to blend the simplicity and power of PHP with evolving software engineering principles and tools to easily develop code that is easy to maintain. With this book in hand, you know how to avoid getting muddled up while working in a team and achieve success on your project with effective team work.

Organizations choose PHP as the preferred language for complex web applications because it is battle tested, hardened over time, and proven to work. Thus, chances of the software project you are involved with being PHP-based, are very high. Soon, you will need to explore the technical as well as non-technical aspects that are important to achieve success in PHP team projects of this kind. This book starts by explaining the need for teams working on complex software projects. You learn how you can divide the complexity of PHP projects with the help of the MVC pattern and the use of frameworks. It then discusses the need for a process and how you can choose the right process. It teaches you how to use agile principles to deliver working software for customers, and how to make sure that the team collaborates effectively. Towards the end, the book emphasizes continuous improvement in process and product as well as the people involved. You learn how to ensure that your team is open to change and user feedback, and has the right mindset about quality and other project-related aspects.

Publication date:
September 2009
Publisher
Packt
Pages
184
ISBN
9781847195067

 

Chapter 1. Software is Complex

Useful software evolves over time in order to adapt to the ever changing environment and to cope with the ever increasing demands in the real world. Therefore, useful software becomes increasingly complex over time. This phenomenon applies to PHP applications as well.

During the early days of PHP, the systems written were fairly simple and straightforward. In fact, when Rasmus Lerdorf first developed PHP, the objective was very simple—'Make my life easy with dynamic web applications'. It was a one person effort to start with. Over a period of time, more and more individuals got interested in PHP and used it for their own web applications. Their applications were simple, hardly exceeding 100 PHP scripts and, more often than not, managed by a single person.

As more people gained interest in PHP, for its simplicity and ease of use, the number of use cases increased. This resulted in people wanting to do more with PHP, especially with the rise of the Internet and enterprises looking into using Internet for business applications. The Novel Applications of the Web 2.0 era also increased the demand for rich applications on the Web, along with the need for powerful programming options.

PHP, as a scripting language, has evolved remarkably to meet up to the new requirements. Therefore, as we all know, PHP became the language of choice for the majority of complex and interesting applications that are deployed on the Internet today.

If you look around the Web, some of the most used applications such as Flickr (http://www.flickr.com/) and Facebook (http://www.facebook.com/) are PHP-based. Any web hosting solution that is found around the Web today provides support for PHP. Drupal (http://drupal.org/), Joomla (http://www.joomla.org/), and WordPress (http://wordpress.org/), the popular content management systems that are deployed by millions, are all PHP-based.

As the adoption of PHP becomes wider and the use becomes broader, the feature set and tools continue to expand. At the same time, organizations tend to choose PHP as the language of choice for complex web applications, because it is battle tested, hardened over time, and proven to work. Thus, the chances of the software project you are involved with being PHP-based is very high. Also, the number of organizations that use PHP-based tools is also high. The following image shows the popularity of the programming languages (Source: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html):

The leading programming languages, Java, C, and C++, are very different form PHP. Java and C++ are used to implement enterprise as well as desktop applications. Many people still use C to implement systems software such as operating systems. Even the PHP engine is implemented in C. On the other hand, PHP is popular in a very different domain, namely Web Programming. As you can see, PHP is the leader when it comes to web-based programming.

Be it that your software project is using PHP or a tool based on PHP, given the complexity of today's software, you need a team of people. In other words, the days when one person could handle the development of a platform are long gone. Today's web applications are much more complex compared to the private home pages. For example, the PHP-based web application platforms like Flickr are quite complex web applications that are completely written in PHP. We are also seeing that blogging web applications are replacing private web sites at a very fast rate, and the blogging platforms are completely implemented in PHP.

In this chapter, you will learn:

  • The need for teams for PHP projects

  • How software engineering principles help with PHP projects

  • The need for a process for PHP projects

  • Dividing the project problem and conquering it

  • How patterns help with PHP projects

  • Using tools to manage the development and collaboration within the PHP team

 

Need for teams


We need the help of a team of people to successfully implement a solution to a complex problem. When we are trying to implement a solution for some problem, one of the obvious questions would be whether to implement the solution on our own or to look for ready made solutions which are available out there. There are many hosted solutions that can be found on the Internet for individual use these days. For example, you could go to a web hosting site and deploy your web site based on WordPress. You can also use one of many blogging tools and make it your home page. So if the task is simple, there is no point having a team of PHP developers to do the job. If the problem that we are looking to solve is complex, and if there are no readymade solutions available out there, we need to form a team to help solve the problem. Sometimes, we'll be able to find open source projects that solve the problem that we have been looking to solve. However, most of the open source projects are looking to solve generic problems. Most of the enterprises would have unique business problems to be solved. Hence, we might need a team of developers to implement that custom solution for the enterprise.

Implementing a more customized, value added, enterprise applications requires a team of developers. This is required, especially, given today's competitive marketplace, and given that almost all organizations make use of information technology. It is not the mere existence of a software application that matters most today. Rather, the application should meet the expectations of the enterprise, by being agile, flexible, and designed to deal with the ever changing business environment. For example, take a developer portal; you can easily use a content management system such as Drupal or Joomla! for hosting it. However, to customize it to meet the organizational objectives and maintain it over time, you might need more than one PHP developer—and that is a team.

If you look into a more complex enterprise scenario, such as online trading or social networking, your team could consist of around 10 to 100 people, or even more. Many PHP-based dynamic web sites could be managed effectively with about two good PHP developers. However, the number of members that you need in a team is very much dependant on the nature of the PHP project at hand. Apart from the design and coding activities, we need to take into account the testing and documentation effort in a project. We might also need to take into account the effort required to maintain the software, providing bug fixes, and facilitating change requests.

So it is obvious that you need a team, and you might already be part of a team. Perhaps this is the reason why you are reading this book, or you might want to join on organization where there are teams.

 

Software engineering principles to help


People have worked as teams on software projects for many years. Can the same techniques be used for your team PHP project? Yes they can. Then why read this book, and not read a regular book on software engineering? It is always good to have an understanding of software engineering principles, but in this book, we will explore how to blend the simplicity and power of PHP with evolving software engineering principles and tools. For example, how do you blend the agile process with tools such as Wikis and forums? This book will guide you to improve your success rate with projects, involving PHP.

In software engineering, there is a concept called process rigor. Based on the nature of the team and the technologies used, you can afford to vary the rigor with which you follow the process. You need not stick to the theory of the process, rather follow it the way that is most suited for your team. The process should help you get there and build a quality product. The process should help, and not hinder.

Many people associate PHP with simplicity and overlook the need to be declined when working with a team. This is also partly related to the fact that many complex programming constructs can be implemented very simply with PHP. For example, compare Java code for reading a file with that of PHP.

The following is the Java code for reading a file:

import java.io.*;

class ReadFile {

public static void main(String args[]) {
  try {
      BufferedReader in = new BufferedReader(
	  new FileReader("test.txt"));
      String str;
      while ((str = in.readLine()) != null) {
        System.out.println(str);
      }
    } catch (IOException e) {
    }
    }
    Finally {
      in.close();
    }
}

The following is the PHP code for reading a file:

<?php
echo file_get_contents("test.txt");
?>

However, the fact that the programming language is simple and powerful does not mean that the nature of the software that you develop is simple. PHP is simple because it is less strict compared to Java or C++. Typepage, syntax alternatives, flexible parameter width, and so on, make it easier for writing something in a quick 'n' dirty style. Unfortunately, that is one of the areas where it gets complex for big projects with teams. If you give more parameters than the function reads, nothing will notify you. If you take the size of the API as criterion of simplicity, Java should be simpler than PHP because there are some functions, like System.arraycopy(), String.endsWith(), that you would need to implement by hand in PHP. So while PHP has evolved to a level where it can be used for complex projects, we also need to pay attention to these finer aspects that decide our success.

When you learn the programming language, you often worked on your own, but on your day job you need to work with other people. What you develop needs to work with what others develop. And if you build Application Programming Interfaces (APIs), others need to use those and you also need to use APIs implemented by others. APIs are the means by which we can share the functionality that we implement with other developers. When a certain PHP class or function has widespread use, we can hide the implementation details behind the API and share only the API with the rest of the world. This is a very powerful mechanism while breaking down the system into manageable sub-parts and getting various team members to work on them.

Use a process

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.

Note

The values emphasized by agile methodology are:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

(Source: www.agilemanifesto.org)

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.

Divide and conquer

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.

Guarantee reuse

Make sure that common functionality and common classes are not duplicated and not written multiple times by various team members.

In the evolution of programming techniques, people have moved from functional programming to Object-Oriented Programming (OOP). In the functional approach, a program is a collection of function calls. While this technique helped us achieve some level of reuse, when it comes to maintaining the system, the life gets harder. This is because the data manipulation in the system is spread across the system, and controlling which function changes which set of data is hard.

To solve the problem of uncontrolled data, people came up with the concept of encapsulation is the object-oriented paradigm. The rationale was to encapsulate the data and functions that process those together into a concept called an object class. Related data would be kept together, along with the methods that process them, so that it is clear, which method changes which data. In object-oriented programming, a program is a collection of objects, and an object is an instance of a class, which encapsulates the data and related functions.

While in functional programming, the units being reused are functions, in object-oriented programming, the unit of reuse is a class. The key difference is that in a functional case, there is no control over the data reuse, while in object-oriented programming, the object classes being reused have both data and methods that process those encapsulated together.

Be it fictional programming that you are using or object-oriented programming, you need to make a conscious effort to pay attention to reuse. It must also be noted that the object-oriented programming style encourage reuse naturally, and therefore it is easier to achieve reuse with object oriented design, compared to a functional design.

Guarantee integration

The 'I did my part my way' kind of mindset is not going to work in a team setup. Especially when it comes to API design, we must find common ground, and make sure that all of the members of the team understand the conventions and norms used. Even when doing the internal implementation, the individual programmer can tend to assume that it is his or her own code and follow personal preferences. But in a complex system, when you think of bug fixing or improving the functionality of a given piece of code and the original programmer is not around, the other team members should be able to manage the situation. Therefore, even the variable naming and the algorithms used have significance in a project done by a team of developers.

Make sure that what you do does not break what others have done and vice versa. After all, everything that the members of the team implement needs to work together as one system.

Changes are inevitable. Any living software system must change and evolve, to adapt to the changing real-world conditions, for that system to be useful.

Prevent regression

When multiple people work in parallel, the chances of bugs being introduced in the system is very high. It is always a good practice to keep the system at a working and operational state, irrespective of missing and yet to be implemented features. One of the most well known techniques to keep the system working all of the time is to make sure that there is a comprehensive set of unit tests. At least all of the major functionality, if not all functionality, must be covered with a unit test. This way, whenever you make a change or update, we can run the test suite to ensure that nothing has broken. That simply ensures that the team would end up with a high quality working system. Deferring bugs until late is not a good practice, and will demand more cycles from the team members in the long run.

Vertical versus horizontal division

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

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 as solutions

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.

Note

Model View Controller

Model: It represents the data on which the application operates

View: It renders the data from the model into a form suitable for interaction, typically a user interface

Controller: It responds to events, typically user interactions, and may invoke changes on the model

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.

Process for success

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.

Note

The agile process promotes development iterations where tasks are done in small increments with minimal planning, rather than long-term planning. Success with an agile process also depends on teamwork, collaboration, and process adaptability throughout the life cycle of the project.

 

Tools


For any project, we need the help of tools in order to be successful. Earlier in this chapter, it was explained how complex today's software projects are. We discussed the need for teams of software developers. Likewise, tools are essential for the success of software projects these days.

Tools make sure that we make fewer errors, be consistent with our approach to design, development testing, and that we are effective and productive in the way we approach the project.

We can seek the help of tools for source control, automated unit testing, issue tracking, communication and collaboration. Without proper tools, it would have been hard, if not impossible, to achieve success in these areas of a project.

Source code control

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.

Continuous builds

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.

Issue tracking

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

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.

 

Summary


In this chapter, we discussed why we need teams to work on software projects, and in particular, on PHP software projects. Along with the evolving real world requirements, the PHP software too needs to evolve, thus they become complex over time.

Since PHP is being used for complex enterprise systems nowadays, we need help from the software engineering principles to deal with the PHP projects. However, given the power and simplicity of PHP, we can choose the rigour process to suite our needs.

Separation of concerns helps us deal with complex projects, dividing the problem into smaller, more manageable parts. Dividing the system based on cross-cutting concerns help teams to deal with complexities easier.

Continuous integration, use of patterns and using the right process, help achieve team success with any software project. For PHP, MVC is the most used pattern. Given the power and simplicity of the PHP programming language, we can leverage the agile process values for PHP projects.

Source control tools, issue tracking tools, continuous builds, and tools that help with proper team communication such as Wikis, forums, mailing lists, and instant messaging chat rooms can be used to improve your team PHP project success.

In the next chapter, we will explore the MVC pattern in more detail and discuss how we can ensure a team can get involved with the MVC pattern in a PHP software project.

About the Author
  • Samisa Abeysinghe

    Samisa Abeysinghe is Director, Engineering at WSO2. Samisa pioneered the Apache Axis2/C effort and architected the core of the Apache Axis2/C Web services engine. He continues to be an active contributor in the Apache Axis2/C project. His involvement in open-source projects began in 2004 when he started working with the Apache Axis C/C++ project.

    Prior to his current role, Samisa played the project lead role for the WSO2 Web services Framework for PHP project, which provides comprehensive support for building both SOAP and REST services and clients.

    Browse publications by this author
PHP Team Development
Unlock this book and the full library FREE for 7 days
Start now