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.
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.
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.
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.
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.
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.
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.
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.
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.