Как POD помог мне
Я хотел бы рассказать о случае из моего опыта разработчика, когда POD существенно помог мне.
Работал я в одном стартапе. Это было относительно давно, тем не менее эта история может кому-то пригодится. Как и в любом стартапе, в самом начале его существования отсутствует какая либо жесткая субординация (как впрочем и бюрократия). С одной стороны в самом начале проекта необходима максимальная отдача от всех, с другой стороны в небольшом коллективе граница между руководителями и подчиненными весьма призрачны. Так же нет четкой границы в обязанностях.
Я начинал работу в таком стартапе как разработчик некоего интерфейса для партнеров проекта (пусть это будет "панель управления").
В стартапе была небольшая иерархия и сразу же после моего руководителя шел генеральный руководитель - Антон (имя изменено). Коллектив был небольшой и по большей части в те года молодой и малоопытный. Было увлекательно вести разработку непосредственно своего проекта и участвовать в решении архитектурных проблем остальных (мой админский опыт способствовал этому).
Однажды, вызвал меня к себе генеральный руководитель - Антон. И попросил сделать небольшое Web приложение, которое помогло бы ему проверить ряд его теорий. Он вкраце очертил задачи, поинтересовался сроками и мы договорились встретится через неделю, чтобы обсудить прототип.
![](/_next/./static/assets/note1-29c19051f5886e9f..jpg)
Во время разговора я делал небольшие пометки в блокноте, в том числе набросал начальный интерфейс. Интерфейс предполагал некоторое количество настроек, каждая из которых влияла на параметры для извлечения данных из одного проекта, фильтрацию полученных данных на основе информации из другого проекта, затем повторную выборку дополнительных данных и так далее. То есть были задействованы данные из разных проектов, в которых я не участвовал и мне необходима была помощь каждой из команд.
Это вполне себе нормальная ситуация. Для начальной реализации мне достаточно было подойти к разработчикам обоих проектов и узнать технические детали их баз данных. Первый прототип был готов в указанные сроки и был продемонстрирован Антону. Здесь начались первые сложности. В подготовленном приложении обнаружились неточности в реализации логики и у Антона появились новые идеи (!).
Естественно замечания и пожелания были в очередной раз выполнены, и снова в результате обсуждения обнаруживались ошибки в уже существующей и ранее одобренной частях программы.
Стоит отметить, что все это время я делал заметки в блокноте, отмечая основные моменты в процессе беседы. Каждой раз я начинал записи на отдельном чистом листе. После пары встреч, я стал замечать, что некоторые замечания Антона начинают противоречить ранее сформулированным задачам. Тем временем из казалось бы простой задачи на одну страницу блокнота, процесс увеличился на десяток исписанных страниц A4.
Так как, для реализация логики необходимы были данные из нескольких независимых проектов, это вносило еще один тормозящий фактор. Дело в том, что проекты быстро развивались и при этом менялась структура хранилища одного из них. Попросту говоря, мои SQL запросы переставали работать.
Все вместе это приводило к возникновению задач по поддержке работоспособности уже созданного кода и вместе с изменчивым мнением Антона грозило перерасти в довольно некрасивую ситуацию.
Именно в этот момент и был составлен документ Технического Задания! В него я перенес все задачи из блокнота по итогам последних встреч, а также сделал отдельный раздел, в котором в виде списка перечислил последовательность действий программы. Приведу пример одного из такого пункта:
=item * Фильтрация по рубрикам (filter_by_rubrik)
Фильтр по рубрикам. На вход передается идентификатор произведения (bookid) и
его рубрика является фильтром для всех остальных книг.
* запрос на получение идентификатора рубрики (база произведений)
______________________________________________________________
______________________________________________________________
Подготовленные строки предназначены для запросов к базам данных. С данным документом я подходил к разработчикам проектов и просил заполнить запросы для их баз данных
Теперь я распечатывал перед каждой встречей с Антоном последнюю копию этого документа и отмечал замечания по ходу беседы непосредственно в нем. Этот документ стал предметом обсуждения!
Данный документ был наглядным представлением задач с видимыми объемами работ и условиями их выполнения. Наличие этого документа, круто изменило процесс решения исходной задачи. Теперь объем и содержание работ стал очевидным. В случае изменения структуры баз данных я просил разработчиков исправить старые запросы на новые. Первоначальная задача была решена в течении пары недель, хотя с момента ее формулирования прошло полтора месяца.
Конечно, не случайно в качестве формата технического задания был выбран POD, но на его месте мог быть любой другой формат разметки. Тем не менее, я благодарен формату Perl 5 POD за его помощь, хоть и пишу сейчас Технические Задания (как и текст этого поста) в формате Perl 6 Pod !
![](/_next/./static/assets/note2-9bb2e49a806dd643..jpg)