Эффективная реализация задачи

В данном документе описывается принцип реализации задачи так, чтобы и разработчику было комфортно и быстро для бизнеса.

Важно, читать данный документ нужно после документа о RDD.

Предварительная реализация

Практика показывает, что лучше сначала сделать так называемый MVP (Minimal viable product), а потом полную реализацию.

Поэтому, предлагается такой порядок действий разработчика по выполнению задачи:

1. накидать скелет кода (имена методов без реализации)
2. накидать тесты на скелет кода (пусть даже тесты еще не проходят)
3. оформить PR (Pull Request) / MR (Merge Request) и пройти предварительное ревью

Можно даже в таком виде:

/**
 * Кратое описание для чего нужен метод, что он делает
 * Что метод возвращает и для чего это можно использовать
 * и т.д. и т.п.
 *
 * @param string $params_name1 Описание входящих параметров
 * @return bool Описание что именно возвращает данный метод
 */
public function isStringValue($param_name1);
return boolean; throw cantCheckStringValueException;

// Основные примеры тестов
$phpunit->assertTrue($this->isStringValue("parameter value"));
$phpunit->assertFalse($this->isStringValue(12345));

Тесты

Как же можно писать тесты до того, как написан сам функционал? Вы уже написали README, значит прекрасно знаете какие "внутренности" должны быть у задачи.

Комфортная разработка

Комфорт для разработчика это:

• минимальное количество исправлений
• минимальное количество итераций ревью
• минимальное количество написанных тестов

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

Шаг 1 (когда задача не готова к разработке):

1. Разработчик исследует задачу и пишет план реализации (если таковой не описан в задаче)
2. Задача получает одобрение плана и оценку согласно этапам одобрения (например: руководитель одобряет план и дает оценку)

Шаг 2 (когда задача готова к разработке):

1. Разработчик пишет предварительную реализацию
2. Руководитель одобряет предварительную реализацию

Шаг 3 (когда задача готова к разработке):

1. Разработчик пишет полную реализацию
2. Другие разработчики в команде одобряют полную реализацию
3. Руководитель одобряет полную реализацию
4. Разработчик отправляет задачу в тестирование

Маленькая задача

Для небольших задач выше указанная стратегия является избыточной, достаточно двух шагов: 1 и 3.