Комментарии 23
И тогда я задумался: когда же будет устранен этот «костыль»?
У нас на прошлом проекте с этим было довольно просто. В коде запрещены TODO и FIXME без указания таска в трекере. То есть любитель спагетти должен сам пойти и создать на себя техдолговой таск, где описано что не так и что с этим делать. Пару раз это даже приводило к тому, что тудушка исправлялось прямо здесь и сейчас безотлагательно.
Ну а вообще серебряной пули, конечно, не существует. Этот разговор - в конечном итоге разговор об инженерной культуре. Она взращивается годами как усилиями технической элиты организации так и грамотной стратегией найма. Странно же, например, нанимать в оркестр дворовых гитаристов, а потом удивляться, что они Баха осилить не могут.
Да, и в итоге у вас часть тудушек просто отсутствует, потому что кому-то из команды было влом заводить для неё задачу. И вы наблюдаете уменьшение количества тудушек, но не в состоянии сказать, стал ваш код лучше или же просто костыли теперь никак не подсвечены
При наличии кодинспекции костыльные места не оформленные в задачу переводятся в таковые и потом работа вливается в основную ветку (ну а может быть и исправляется сразу). Это делается либо автором по результатам приемки, либо сразу принимающим безальтернативно для сдающего.
Вы не поняли механизм.
Ревьюер: Так не делается, надо исправить.
Кодер: Ок, сделаю туду.
Ревьюер: Без таска на туду реквест не одобряется.
У кодера вариант или таки заводить таск или исправлять сейчас.
беру на вооружение, спасибо.
как часто это приводит к конфликтам типа:
Менеджер: нам нужна фича ещё вчера!
Тимлид: нам нужно оформить таски на техдолг, потому что инженерная культура
Команда/разработчик: фича сделана, там опять этот душнила упёрся со своим оформлением техдолговых тикетов, которые никто никогда не разгребёт!
Как решаются?
Элементарно. Делается задача, кладётся в backlog, никогда не выполняется.
Менеджер и техлид запихиваются в комнату (можно виртуальную). Как примут совместное решение - можно выпускать.
Для начала надо понять, как дошли до жизни такой. ПМ с тимлидом друг друга впервые видят? Тимлид нанимает в команду людей, которые не разделяют его ценности? Или тимлид пришел в команду без карт-бланша на установление своих правил? Такая ситуация пахнет каким-то базовым факапом.
Делается релиз план на следующий мажорный релиз и расписываются желаемые фичи с приоритетами. А дальше всё зависит от ресурсов разработки. Какие то фичи уйдут в следующий релиз, какие то отпадут со временем. Какие-то заказчик таки получит :)
А почему откладывать дела так легко? Мне нравится одна из идей, которые я ранее где-то читал. А именно: человек считает себя будущего не собой, а как бы другим человеком. Нет полной внутренней идентичности. На другого легко свалить выполнение задачи. Легко представить, что у него нет того миллиона причин, которые ты имеешь сам, чтобы эту работу не делать. А когда наступает будущее и это опять оказываешься ты сам, то у тебя опять оказывается миллион причин не делать отложенное. Ибо у тебя и в прошлом этих причин было миллион и ты их не смог пересилить. Они все на месте. И вот ко всему этому ещё добавлется то, что уважаемый автор описал в своей статье. Что усиливает желание ещё отложить
Господи, какие все божие одуванчики - работают за идею и интерес.
Мне тоже интересно программировать и улучшать код - но надо и денежку заработать и мне пофигу кривизна в коде пока работает - чинить за бесплатно времени просто нет, есть другие проекты. Но если платят за устранение техдолга - то почему бы и нет.
Бабло победит зло.
Именно поэтому в адекватных проектах учат/учатся/научились либо исправлять сразу, либо планировать исправления, либо релизить "не сейчас", также как и нанимать умеющих в инженерную культуру, и дальше по списку. Потому что понимают, что "жить на костылях" всегда выходит дороже. В таких, где так не делают, с годами проект "почему-то" тонет.
Из одного такого я ушёл именно потому, что источником неадеквата был главный ПМ, и перевести всю культуру разработки на надёжные рельсы в обход него было просто невозможно. Если конкретно: он себе сделал супер-админа и пушил в основную ветку без ревью от слова вообще. А так как его стиль написания кода был из-за его гениальности "исключительным", на поддержке разобрать такое не мог почти никто, и все страдали. И это только вершина айсберга.
Согласен полностью, что жить на костылях не удобно, но не надо забывать кто будет жить на этих костылях - будущий Гомер или люди из другого района. Если сам пишешь...сам сопровождаешь и за это денежку получаешь, то это одно ... красивый код - это твоя инвестиция в будущий доход. Если же пишут одни, сопровождают другие, то каждый пытается оптимизировать свои доходы. Полный говнокод писать тоже неприлично - чтобы репутацию не портить, но и напрягаться на будущее смысла нет, тем более часто в процессе написания у заказчика меняется бизнес-логика и приходится переделывать многое.
В реальной разработке костыли необходимы. Иногда изменения запрещены, и нужно делать быстрый хотфикс с минимальными изменениями.
Это называется техничечкий долг, и в нормальных условиях на это выделяется время.
В любом случае, рано и поздно, костыль будет переписан. Но если поздно, то придется полностью переписывать большой кусок кода. Иногда это единственный вариант, из-за спаггети-кода в котором невозможно разобраться.
Кода проблем и багов с конкретным кодом накопится достаточно, то их скопом можно решить полной переделкой. Иначе не выделят время. По времени это будет в любом случае быстрее.
Статья актуальна не толлько для работающих в IT, но и для студентов данной сферы. Однозначно стоит скинуть друзьям, жаль, что никак руки не доходят их завести. Потом исправлю это.
Не обманывайте себя: вы не «исправите это потом»