Как спланировать и структурировать гибкий проект, использующий фреймворк?

Предполагая, что вы будете использовать проблему & Программное обеспечение для отслеживания проекта, как Jira, для планирования вашего следующего предстоящего проекта.

Вы решили использовать веб-фреймворк PHP, как Laravel, для разработки веб-приложений по архитектурному шаблону модель-представление-контроллер (MVC).

Вы пишете свои проблемы в виде пользовательских историй, добавляете некоторые детали и так далее.

[Пользовательский — Компонент]

• Как пользователь, я хочу иметь возможность управлять пользователями.
  • Как пользователь, я хочу иметь возможность зарегистрировать нового пользователя.
  • Как пользователь, я хочу иметь возможность удалить существующего пользователя.
    …

[Специфическое сообщение — Компонент]

• Как пользователь, я хочу иметь возможность общаться.
  • Как пользователь, я хочу иметь возможность отправлять сообщения пользователю.
  • Как пользователь, я хочу иметь возможность получать сообщения от пользователя.
  • Как пользователь, я хочу иметь возможность использовать смайлики в сообщении.
  • Как пользователь, я хочу иметь возможность прикреплять файлы к сообщению.
    …

[Задача конкретная — Компонент]

• Как пользователь, я хочу иметь возможность иметь доску задач.
  • Как пользователь, я хочу иметь возможность добавлять новые задачи.
  • Как пользователь, я хочу иметь возможность назначить задачу пользователю.
  • Как пользователь, я хочу иметь возможность пометить задачу как выполненную.
    …

Ты понял?! Нет проблем на данный момент. Некоторые из историй могут быть даже разбиты на более мелкие истории, а затем и на некоторые задачи, сопровождаемые некоторыми подзадачами.

Давайте сделаем еще один шаг: вы используете Collaborate Platform с исходным кодом, например GitHub, в сочетании с Fish-Eye и решил использовать смарт-фиксаций к вопросам перехода. Ваши проблемы и коммиты хорошо структурированы и легко отслеживаются. (Красивые мысли)

Если вы следуете руководству в рамках инфраструктуры, у вас будут другие задачи:

• База данных (с отношениями)
• Модель (с отношениями)
• Controler
• Маршруты (API)
• Просмотры (пользовательский интерфейс)
• Validations
• События
• Validations
• Ошибки / Исключения / Ведение журнала
• …

Это, и даже больше задач, должны быть выполнены, чтобы подтвердить компонент как выполненный. И под компонентами я подразумеваю определенные выше, такие как Пользователь, Сообщение, Задача. У всех них есть что-то общее, что вы бы повторяли снова и снова. Но все же вы хотите, чтобы проблема была заполнена исходным кодом, который необходим для ее полного устранения.

User.php (Модель отношений)

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
/**
* Get the message record associated with the user.
*/
public function message()
{
return $this->hasOne('App\Message');
}

/**
* Get the task record associated with the user.
*/
public function task()
{
return $this->hasOne('App\Task');
}
}

Task.php (Модель отношений)

use Illuminate\Database\Eloquent\Model;

class Task extends Model
{
/**
* Get the user that relies the task.
*/
public function user()
{
return $this->belongsTo('App\Task');
}
}

message.php (Модель отношений)

use Illuminate\Database\Eloquent\Model;

class Message extends Model
{
/**
* Get the user that relies the message.
*/
public function user()
{
return $this->belongsTo('App\Message');
}
}

Приведенный выше код — это только одна часть необходимых задач, чтобы обеспечить выполнение компонента. Это будет похоже на другие задачи. (db-миграция, контроллер, просмотр, проверка, события и т. д.)

Итак, как бы вы приняли это во внимание, если вы планируете проект, который следует руководящим принципам структуры?

Цель состоит в том, чтобы компонент состоял из всех упомянутых задач, прежде чем его можно будет подтвердить как выполненное.