Технический долг

·

Технический долг - слишком заезженный термин в разработке. Проблема с тем, что сюда входят два понятие:

  1. технический долгом можно считать, когда старый код не соответствует новой информации.
  2. технический долг - пишем плохой код, который мы сразу хотим переписать.

Короче, у меня тут прозрение такое случилось про техдолг. Знаете эти картинки в учебниках по физике, где человека представляют червяком в 4D пространстве. Никогда не понимал зачем их показывать, потому прикладного смысла в этом не было. А тут щёлкнуло, что технические сервисы тоже во времени живут и можно нарисовать текущего червяка для архитектуры. Точнее когда кто-то показывает набор плоских кубиков последовательно, то это разрезы того же червяка.

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

Да, понятно что это можно проще сказать “типа мы накосячили с решениями в прошлом”, но мне интересно можно ли переложить на это какие-то вещи из математики и считать например на основе git (это ж машина времени) точнее такие точки, которые как бы “выгибают” систему во времени. Все текущие тулы считают либо горячие узлы (слишком часто меняются), либо холодные (не менялись X времени). А нам условное натяжение всех последующих строчек от текущих посчитать.

У меня вот пример под руками с расписанием методистов, которые решили хранить понедельник (1) в UTC (2) условно год назад, и жопа в тот момент когда пришли хранить расписание в латинской америка, которое перескакивает между неделями.

Дополнительные заметки