The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
PDD, или Puzzle Driven Development, - это метод, используемый для разбиения программных задач на более мелкие и обеспечения их параллельной реализации. Метод PDD широко используется в методологии XDSD. Этот метод ожидает патента USPTO (заявка № 12/840,306).
Давайте рассмотрим этот метод на примере. Скажем, вы программист и вам поручено разработать и реализовать Java-класс. Вот формальное описание задачи: “класс DBWriter должен расширять абстрактный класс java.io.Writer и сохранять все входящие данные в базе данных”.
У вас есть один час на реализацию этой задачи. Вам ясно, что одного часа недостаточно, потому что проблема гораздо больше и требует больше работы, чем позволяет выделенное время. Кроме того, имеется множество неизвестных:
Что такое схема базы данных? Является ли она SQL или NoSQL базой данных?
Как подключиться к БД? JDBC? JPA? DAO?
Как обрабатывать исключения?
Давайте учтем все эти неизвестные, пытаясь решить проблему на самом высоком уровне абстракции. Конечно же, мы начинаем с теста:
В приведенном выше тесте мы определяем ожидаемое поведение класса. Тест не компилируется, потому что отсутствуют два класса: DataBridge и DBWriter. Давайте сначала реализуем мост.
Далее - сам писатель:
С использованием вышеприведенного кода мы решаем проблему. В данном примере мы успешно разработали, реализовали и протестировали необходимый класс DBWriter. Впоследствии, данный класс теперь может быть непосредственно использован “как есть” другими классами.
Конечно, реализация не завершена, так как мы не записываем ничего в базу данных. Кроме того, мы все еще не отвечаем на большинство вопросов, заданных в примере сценария. Например, мы все еще не знаем точно, как нужно подключаться к базе данных, ее тип (SQL или NoSQL), правильный формат данных и так далее. Однако мы уже сделали ряд важных архитектурных предположений, которые позволили нам реализовать класс и сделать его используемым другими классами.
Теперь пришло время идентифицировать неизвестные моменты в нашем коде и пометить их головоломками. Каждая головоломка - это запрос на уточнение. Мы хотим попросить кого-то другого помочь нам уточнить и исправить наши предположения. Вот первая головоломка, которую нам нужно добавить:
Головоломка состоит из трех элементов: метки @todo, локатора #123 и комментария. Локатор отображает следующее: “Головоломка была создана при работе с тикетом #123.”
Добавим еще одну головоломку:
Эта головоломка указывает на одну из наших забот, потому что мы не уверены, что архитектурное решение правильное. На самом деле, дизайн в данный момент очень примитивный и, скорее всего, неправильный. Чтобы его усовершенствовать и переработать, нам требуется больше информации от определителя задачи.
Задача завершена. Теперь вы можете интегрировать свою ветку в master и вернуть тикет тому, кто его вам назначил. Его задача сейчас - найти других людей, которые смогут решить головоломки, которые мы только что создали.
Каждая созданная сейчас головоломка будет порождать другие головоломки, которые будут решаться другими людьми. В результате наша простая задача на час может потенциально породить сотни других задач, которые могут занять дни или даже годы для выполнения. Тем не менее, вашей целью при работе с вашей конкретной задачей является ее как можно скорее завершить и интегрировать свою ветку в master.
Есть несколько простых правил, которые помогают правильно размещать головоломки.
Во-первых, вы должны размещать свои аннотации @todo в том месте, где ваш код сталкивается с заглушкой. Например, в модульном тесте. Вы реализуете тест, и он не проходит, потому что класс еще не реализован. Вы пропускаете тест с помощью аннотации @Ignore и добавляете головоломку @todo в его JavaDoc.
Во-вторых, ваша головоломка должна оставаться как можно ближе к элементу кода, который сталкивается с заглушкой. Предположим, у вас есть модульный тест с тремя методами тестирования. Все они сейчас не проходят, потому что класс не реализован. Лучшим подходом будет проигнорировать каждый из них и создать три (!) головоломки. Каждая из головоломок должна объяснить, что вы ожидаете от класса и как его следует реализовать.
В-третьих, старайтесь быть максимально описательным. Ваша головоломка вскоре станет задачей для кого-то другого. Поэтому четко объясните, что вы ожидаете от следующего исполнителя, как это сделать, какую документацию использовать и так далее. Должно быть достаточно информации, чтобы следующий исполнитель, назначенный на головоломки, мог реализовать требуемые классы без дополнительной информации от вас!
Кстати, процесс сбора головоломок может быть автоматизирован с помощью нашего PDD Ruby-дополнения и хостингового сервиса 0pdd.com.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 15:50
