Re: On technical debt
| From: | Daniel O'Connor | Date: | Fri, 08 Oct 2010 07:57:21 +0000 |
| Subject: | Re: On technical debt | ||
| References: | 1 2 3 4 5 6 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-53845@lists.php.net to get a copy of this message | ||
> In regard to the current state of PEAR2 and pyrus - I know that an
> issue can be that with the complaining some of us, e.g. myself, seem
> ungrateful for what has been done already. I am really not. I'm just
> not happy with the way things are. But I really appreciate all the
> work that went into it. But I'd also like to be able to help and also
> understand why it's so hard to hold up the principles we enforce for
> contribution in the core code base.
>
> Ditto on that: I'm not trying to attack but analyze - so sorry if this
sounded confrontational!.
> Currently, it's just damn hard to go into code and write tests for it
> if you don't understand it and don't have the time to dive into it for
> a week or so. I also feel that whenever you require people to read
> heaps and heaps of slightly outdated documentation, something is
> wrong. ;-) Feel free to discuss my point of view, but that's where I
> currently stand. Think adoption of the SCS vs. Pirum - the codejust
> has to be easier. No books or docs will help otherwise.
>
>
Agreed. I'm very much in the self documenting code camp here. As a good way
to get into the codebase; why not pick a Pyrus class which is really deep in
the directory structure; and write unit test coverage?
Pyrus\ChannelRegistry\Mirror\XML.php is one I just plucked out at random.
It's near the edge of the object graph, has no dependencies, and is really
simple.
You don't need to know very much about it to write test coverage - infact,
it's probably more beneficial if you put the wrong things into the wrong
places.
In psuedocode; you could write a test like:
$ci = new \PEAR2\Pyrus\ChannelInterface();
$r = $this->getMock('\PEAR2\Pyrus\ChannelRegistry'));
$r->expects($this->once())
->method("update")
->withArgument($ci);
$xml = new PEAR2\Pyrus\ChannelRegistry\Mirror\Xml(array(), $ci, $r);
$xml->setName("potato");
$this->assertSame("potato", $xml->getName());
... and hey presto, you've got a better understanding of the class.
After a while you might start asking yourself why
\PEAR2\Pyrus\ChannelFile\v1\Mirror allows different/looser constructor
arguments, or why a Model type class is notifying other models to update() -
surely this should be done by the code calling it?
Before you know it; out comes a patch or two.
I know the pyrus test cases are not phpunit, but I don't think that matters
too much - it's more the practice of writing a test and realising why it's a
freakin' pain than any specific technology.