laravel下的团队开发

当你的团队在开发一个大型应用时，该应用的不同部分可能以不同的速度前进。比如，设想下面的场景：一个开发热源被分配 数据层 的backend工作，而另外一个开发人员做front-end和web/controller层面的工作。前端开发人员希望测试他的controller，但是后端的数据层却进展缓慢。然而，如果两个开发人员能够在他们之间的接口上预先达成一个协议(interface)，也就是说后端数据层设计人员必须提供以下的数据访问接口，那么后端数据层开发即使进展不能和前端开发完全同步，那么也不会影响前端的开发工作：

interface OrderRepositoryInterface {
public function getMostRecent(User $user);
}

一旦这个接口规范被制定，即便是这时接口的具体实现还根本没有，那么前端工程师就可以测试他的contrller了！这种工作模式就允许应用的不同模块和组件可以以不同的速度向前走，而又能满足适当的unit test的需求。而且，这种工作方法即便我们彻底改变一个接口的实现模式（可能会有bug），也不会break掉其他我关的组件的工作。记住：这里无知便是福。我们不想知道也不应该知道我们所依赖的接口是如何实现的，我们只需要知道该接口提供什么功能即可。所以，既然现在我们有了清晰定义的接口，我们就可以写我们的controller了：

class OrderController {

public function __construct(OrderRepositoryInterface $orders)
{
$this->orders = $orders;
}

public function getRecent()
{
$recent = $this->orders->getMostRecent(Auth::user()):

return View::make('orders.recent', compact('recent'));
}

}

前端工程师甚至可以写一个"dummy"的接口实现，这时应用的view就可以populate一些假的数据了。

class DummyOrderRepository implements OrderRepositoryInterface {

public function getMostRecent(User $user)
{
return array('Order 1', 'Order 2', 'Order 3');
}

}

一旦dummy implementation写出来后，我们可以bind到我们的ioc容器里面，这样我们的整个应用就开始使用这个Dummy implementation了。

App::bind('OrderRepositoryInterface', 'DummyOrderRepository');

经过上述绑定后，一旦一个真实的implmentation被后端工程师开发完成，比如RedisOrderRepository，那么IoC binding就可以非常方便地切换OrderRepoistoryInterface到这个实际的实现上去了，这时整个应用的功能就完整地开始使用村粗在Redis中的订单数据功能了！

正因为interface如此重要，因此在一个项目开发开始前，一定要在相关团队间讨论定义清晰的接口，大家随后可以独自工作，约定一个时间周期来做integration就好了。这就是一个比较ok的PHP 项目实践了