RDD first

Что же такое RDD, и почему его нужно придерживаться, давайте разберемся.

RDD - Readme driven development (разработка через описание задачи и написания тестов).

То есть перед тем, как приступить к непосредственному выполнению задачи разработчик должен сначала составить технический план реализации задачи - описать что потребуется сделать для выполнения задачи и как он собирается это сделать.  После этого он приступает к написанию тестов для своего приложения. И только после написания тестов приступает к разработке функционала, требуемого для задачи.

Для чего нужен RDD

1. RDD заставляет думать перед тем как начать что-либо разрабатывать.
2. RDD дает понимание руководителям о том, что собирается делать программист до того, как программист начинает это делать. Соответственно можно избежать неправильных путей решения задачи.
3. Описание README заставит понять что именно нужно для решения задачи, заставит взглянуть на задачу со стороны
4. Описание тестов предотвратит появление багов до полной реализации функционала, так как если вы описали README, то вы уже знаете что у вас будет на входе и что будет на выходе.

Зачем писать README, если мне и так всё понятно

Затем, что задача понятна Вам только с Вашей точки зрения. А вот является ли Ваша точка зрения правильной, это и даст понять README. Возможно, что кто-то прочитав Ваше README подскажет путь в разы короче, нежели выбранный Вами. Или просто поправит неправильный подход к решению задачи.

Плюс ко всему, чтобы написать README Вам придется узнать задачу от самого начала до самого конца, чтобы она полностью была у Вас в голове. О том как Ваша задача может повлиять на другой, уже существующий функционал. О том как Ваша задача может повлиять на другой функционал, разрабатываемый другими программистами в это же время. И о том, что именно Вам действительно нужно сделать для решения Вашей задачи.

План

Описывает общий порядок действий. Чтобы его составить план, нужно последовательно ответить на вопросы:

1. где будут изменения - какое приложение, библиотека (указывается репозиторий), если мест изменений несколько, то план разбивается на соответствующее количество частей с пошаговым последовательным выполнением
2. что будет добавлено/изменено/удалено в указанном месте (указываются файлы и коротко описываются действия производимые в них)

Пример

Допустим есть задача: реализовать отсылку статистики на e-mail каждый час.

План действий будет таков:

1. Написать общее README по задаче (по сути этот текст уже является частью README)
2. Реализовать класс формирования статистики (получения данных из статистики)
3. Реализовать шаблон формирующий контент письма
4. Реализовать класс для отправки писем на почту (консольная команда)
5. Внести правки в конфиг управления cron
6. Выкатить

Готово.