Что такое RDD?

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

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

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

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

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


Как же можно писать тесты до того, как написан сам функционал?

Очень просто. Раз вы уже написали README, то значит вы прекрасно знаете какие "внутренности" должны быть у задачи.

Правила решения любых задач одинаковые:

  1. Пишите только в стиле ООП
  2. Мельчите! Чем меньше кода содержит каждый класс - тем лучше! Тем легче его тестировать, тем легче его поддерживать.
  3. Чем больше классов, чем меньше кода в каждом классе - тем лучше!
  4. Логику всегда можно разбить на части, но нужно всегда думать что стоит дробить, а что нет.

Какой порядок действий должен быть, когда я приступаю к выполнению задачи?

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

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

Под текстом "Реализовать класс ..." подразумевается написание README и тестов для каждого из классов (если этот функционал еще не реализован, конечно)