In This Chapter
Battling code complexity
Managing multiple developers
Dealing with performance issues
As your application grows in features, it become more complicated. Complexity is the kiss of death in software development. It breeds bugs and makes your code harder to maintain and enhance. To combat this, developers
Use abstraction to hide sub-routines and keep functional code as simple as possible.
Use automated testing to make sure new code doesn't break old features.
In addition to your application's growing complexity, your application will suffer from scaling pains as you gain more users. As your user base increases, so does your server load, disk space requirements, database hits, and Twitter API calls. You must address these scaling issues first, or your application is at risk of crashing.
This chapter is here to warn you of potential growing pains and point you in the direction of potential solutions.
Acceptance testing is done from the user interface side of your application. For example, if your app has a login mechanism, to do acceptance testing on that mechanism means you type a username and password, press the login button and verify the login page loaded. This is the most common and simple type of software testing. Acceptance testing can be done manually by a tester or the developer, but it's difficult and time consuming to test every feature of an application, and do it the same way each time. Fortunately, acceptance testing can be automated.
There are open source acceptance testing automation frameworks for nearly every popular platform, including desktop, mobile, and Web development. Some test frameworks require you to write your testing scripts in their in own language, while other test frameworks allow you to write tests in any language the framework supports. Once the tests are written you can play them back as frequently as you need.
Tip
This beats manually remembering to test the 100 different features in your application every time you make a major change in your code.
To get started with acceptance testing for Web applications, give Selenium (http://seleniumhq.org) a try. Selenium has an optional Firefox extension called Selenium IDE that gives you a visual user interface, seen in Figure 14-1, that you can use to record tests for Web application. Using the visual test recorder and player will help introduce you to automated acceptance testing.
Having acceptance tests for you application will stave off new bugs and allow your application to grow larger.
Warning
The problem with acceptance tests is they can't tell you exactly where in your code the bug is. They can alert you that there is a problem, but you're left with only vague guesses as to what that problem might be.
Unit tests are small tests that cover a functional piece of code. For example, if you have a method that takes two numbers as input and returns their sum, you can test that method by writing a unit test. The unit test passes two parameters to the method and tests whether the method output matches the correct summation of the number. The amount of methods you test is called code coverage. If every piece of code in your application is covered with a unit test, you have 100 percent code coverage.
Tip
The beauty of unit testing is the tests run extremely quickly, and if you write granular tests, when a test fails, you know exactly where the problem is.
Much like automated acceptance testing frameworks, there are open source unit testing frameworks for nearly every popular language. For PHP the popular unit-testing framework is PHPUnit. There is even a wrapper class around PHPUnit in the Zend Framework. You can get more information on writing unit tests in the Zend Framework at http://framework.zend.com/manual/en/zend.test.html
The larger your project team grows, the more helpful continuous integration becomes. If you're still a one- or two-person operation, setting up a continuous integration server is probably overkill, but it could be helpful later in your project's lifespan.
When you introduce new developers in to your team, you increase the chance of bug introductions, and of having developers step on each others' toes. Using version control software is a good way to keep programmers from unwittingly overwriting each others code, but that doesn't stop the introduction of new bugs. To do that, you need to use continuous integration. Continuous integration runs your entire automated unit and acceptance test cases every time a developer checks in code to version control. If a test case fails, the entire team is alerted and the bug is identified, along with the programmer who introduced the bug. Continuous integration is not intended to shame the guilty developer. It's intended to indentify bugs before they slip into production and catch them while the code is still fresh on the introducer's mind.
To set up continuous integration, your team needs to be using version control software, such as Subversion (http://subversion.tigris.org) or Git (http://git-scm.com). Then you need a server running continuous integration software, such as CruiseControl (http://cruisecontrol.sourceforge.net). The continuous integration software will poll your version control system looking for changes or check ins. If it notices a new check-in, it will kick off all your automated test scripts. If a test fails, the version control software will alert your team.
Aside from a growingly complex code base, you must also concern yourself with your application's performance and ability to scale as you gain more users. Scalability is a major problem with Web applications, because all your users are sharing the same server resources. Desktop applications have to share computing resources with the operating system, but in general don't need to worry about scaling with an increase of users, because new users come with their own processor, disk space, and RAM. However, due to Twitter's API rate limits, even desktop and mobile applications have to watch the frequency that they access the API.
One way to desktop and mobile applications manage API limits is by authenticating the user and having them use their own rate limit allowance. The desktop application TweetDeck (http://tweetdeck.com) shows the users their current rate limit in the top right of the application, as seen in Figure 14-2. Web applications can use this same trick for Twitter API rate limits.
Along with making the end user aware and responsible for their own API access, you can cache API data. For example, to show a user's Twitter profile you must request it from the Twitter API. Once you have that data, it's safe to assume it will not change significantly in the next few hours. You can save that data to a database and reuse it, instead of requesting it from Twitter again.
A big bottleneck in scaling Web applications is data storage. Relational database systems, such as MySQL, are commonly run on one server. The problem with this is that eventually you will not be able to upgrade a single server's performance any further. Your only option at that point is to add additional servers and split the work. It can be tricky to divide a relational database across multiple servers. For example, if you're doing most of your data writing to one table, you can't split that table across more than one server without running into data integrity issues. To handle a situation like this, you can fracture your data stores. Fracturing your data means breaking it up into smaller, but logical, pieces. So if your application is constantly writing to a users table, you could split that table up across multiple servers by placing users A-M on one server and N-Z on the other. Another option is using a non-relational data storage system such as CouchDB (http://couchdb.apache.org) or Amazon SimpleDB (http://aws.amazon.com/simpledb). These non-relational systems have the ability to scale and sync data horizontally across servers natively.
Your Web server is also susceptible to performance degradation due to increased traffic. To increase the performance of your Web server you can
Add additional Web servers to your project and use a load-balancing server to direct traffic between your Web servers.
Move your static content, such as images, to Web servers that specialize in serving static content.