Agile (and XP) practices in the PHP universe

Perrick Penet, No Parking

PHP / Zend Conference, San Jose, 2006

What about your code ?

Technical debt

Legacy code

Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.

Technical debt is a measure of how untidy or out-of-date the development work area for a product is. It builds up to create legacy code.

Michael Feathers : Working Effectively with Legacy Code .

Agile motto

You can invest in tools but these don't add value over time : there's no interest over time.

We value individuals and interactions over processes and tools.

Extract from the Agile Manifesto.

Preventing hair loss...

Here's probably what you want to avoid :

...and fighting spam ;-)

Here's probably what automated developer testing can do to you :

Check out other satisfied people.

Confidence and serenity are the magic words here.

You know it works, and you know when it works. So developer testing is good for you.

It may also be a nice way to fight spam at the roots.

Once we eradicate spam about hair loss, we can think of a way of making viagra a thing of the past.

XP values

Version 1.0 : Communication - Simplicity - Feedback - Courage.

Version 2.0 : Communication - Simplicity - Feedback - Courage - Respect.

We'll be back here... with SHIFT + ESC + h

XP practices (2.0)

• Planning = stories, slack time, weekly releases, quarterly rhythm
• Integration = build under 10 minutes, continuous integration
• Team = shared space, full dedicated team, information radiator, energizing work, pair programming
• Development = simple and clean design, TDD & automated acceptance testing

XP practices (2.1)

• Business = daily folllowup, negociate-scope contract, payement upon usage
• Team = continuity, "shrinking", defects analysis
• Development = code & tests, unique source, daily deployement

We'll distinguish between two types of tests : unit and acceptance -- Kent Benk calls this Developer Testing.

Definition of unit test

c2 wiki

• small piece of code (one class, one method, one function, one file)
• in isolation (as much as possible since it's not easy but can use mocks or stubs)
• unambiguous result (True or False)
• automated execution (one button, few seconds)
• by the developer, for the developer

Definition of acceptance test

Also functionnal test : c2 wiki

• large chunck of code (any functional intersection between classes, files)
• unambiguous result (True or False)
• automated execution (one button, few minutes)
• by the client (as much as possible), for the developer

Other tests are also possible...

• scaling / charge resistance
• security : scanmus & others
• health check from inside the software

Unit testing

The SimpleTest documentation and tutorial are really good (I know, I have translated them ;-). Exemples come from those : my goal today is to try and convince you reading those...

<?php
require_once('simpletest/unit_tester.php');
require_once('simpletest/reporter.php');
require_once('../classes/log.php');

class TestOfLogging extends UnitTestCase {
    
    function testCreatingNewFile() {
        @unlink('/temp/test.log');
        $log = new Log('/temp/test.log');
        $this->assertFalse(file_exists('/temp/test.log'));
    }
}
$test = &new TestOfLogging();
$test->run(new HtmlReporter());
?>

What do we get?

Test driven development (TDD)

Once you've written a few test, it may seem tedious at the beginning. Then one day something incredible happen : you modify some code somewhere, then run your test suite and a red bar appears at the other end of your code. You were on the fringe of introducing a new bug and it was discovered automatically. From then on, your investment starts paying back.

You're about to become "test infected".

Writing a test before any code is now your new motto. It has a special rhythm to it :

Well actually, it's more something like :

Other benefits of developer testing

• What the code is supposed to do (Debugger = What it's actually doing)
• Synchronized documentation
• Simpler design
• Closed functional perimeter

For another such list : Keith Ray.

Acceptance testing

Using Selenium (a javascript-based tool driving the browser)

<table><tbody>
<tr>
	<td>open</td>
	<td>http://localhost/app/logout.php?origin=index.php</td>
	<td></td>
</tr>
<tr>
	<td>type</td>
	<td>loginname</td>
	<td>admin</td>
</tr>
<tr>
	<td>clickAndWait</td>
	<td>//input[@value='login']</td>
	<td></td>
</tr>
<tr>
	<td>verifyTextPresent</td>
	<td>Logged in as : admin</td>
	<td></td>
</tr>
</tbody></table>

Broken anything yet ?

Also a "fire and forget" mentality can be dangerous security wise :

File Transfer Pain

FTP is easy enough : can you do better ?

Secure, Simple & Heasy

Thank you so much Sara Golemon for SSH2

Keep it simple

Someone Is GOing TO Need It.

PHP was built upon this simplicity.

The no-framework PHP MVC framework : using a framework is expensive. Just start looking for the good one : Taking a look at ten different PHP frameworks

If you had to remember one thing : DRY, pour Don't Repeat Yourself. Then and only then, will you find out about the true power of design patterns (crutches for your language).

Next time : start with worse

Ask your end-users and find the right dose (ie. PHPDoc is not always THE solution).

Note : never tell your boss about the "blame" command if you don't pair programm

Bindings between SVN and PHP do exists : sometimes very useful (as well as post-commit stuff).

Evening commit, hope. Morning update, despair.

Welcome to the green light district.

Using the green light

Some tools : CruiseControl and Rephlux

Start with PEAR "coding standards" (pear.php.net)

class t_w_d_a() { function f() { ... return $b_number; } function __() { } } class travel_with_delta_airlines() { function wait_15_minutes_on_the_plateform() { ... return $before_it_s_too_late; } }

And think about what the rest of the world will do to you when PHP6 comes along.

Where's my stuff ?

Ruby on Rails : power to conventions fighting against power to XML based configuration in Java Wonderland.

Questions ? Queries ?

Perrick Penet

email [fr | en] : perrick@noparking.net

box [fr] : No Parking

blog [fr] : :: onpk ::

contrib [en] : SimpleTest

community [fr | en] : AFUP | PHPLondon