Техдолг, или бесконечная задача

В разработке столкнулся сегодня с типичной ситуацией, когда взявшись за задачу на полтора-два часа, окунулся с головой в дополнительную разработку и ближе к концу дня уже не понятно было, что я вообще делаю и зачем. Знакомо?

Уже неделю на работу хожу и еще ни разу еще туда не пришел

(с) Внутри Лапенко

Эффект дырявого стека

Данное явление по Джедайским техникам Максима Дорофеева называется эффектом дырявого стека. Это когда вам постоянно прилетают новые задачи и каждую новую задачу вы берете сразу в работу, забивая на предыдущие. Чем это плохо? Вы, как правило, забываете и не выполняете свои собственные планы, ожидания не совпадают с реальностью и прощай удовлетворение от работы.

В моей опыте разработчика эффект дырявого стека проявляется из-за т.н. техдолга и перфекцеонизма.

Разработка в долг

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

(Вики)

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

Лирическое отсупление

У меня так и произошло: я писал пайплайн на pyspark, который состоял из модулей, обрабатывающих данные по цепочке. Мне нужно было обновить первый модуль в цепочке и потом протестить пайплайн в состоянии "до" и "после". Оказалось, что другой, не участвующей в текущей задаче, модуль в пайплайне содержит два костыля, один из них записывал результат пайплайна в фиксированную директорию. Это значит, что я не смогу провести адекватное тестирования и т.д..

В этот момент во мне проснулся перфекционизм: проект можно приблизить к идеалу, а коллегам будет проще и понятнее разобраться в коде, и т.д. Стек задач наполнился воодушевляющими перспективами по доведению моего проекта до состояния идеала в необозримом будущем.

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

Что с этим делать?

А теперь встает вопрос: что в такой ситуации лучше делать и что не делать? Я для себя решил, что точно не хочу испытывать растерянность и непонимание своей текущей цели, как это было сегодня. Поэтому я не советую просто так, в спешке и необдуманно браться за новую задачу.

Я бы предложил обращать свое внимание на неожиданные костыли, продлевающие задачу и оценивать сложность их доработки. Мне важно знать, что тот или иной путь к цели я выбрал самостоятельно. Еще стоит подумать о том, как можно решить всплывшую задачу новым костылем ручным трудом без новых костылей.

Постфактум я понимаю, что мог провести тестирование "до" и "после" без дополнительного рефакторинга, просто переключая вручную хардкодные пути к выходным файлам в пайплайне. Это было бы самое быстрое решение, которое не создает дополнительных костылей, но и не улучшает ситуацию в будущем.

Вывод

По итогу: техдолг - объективная реальность любого программного проекта и нужно уметь подходить к его поддержке осознанно.