Connect with us

Разработка

Григорий Петров: Технический долг и как его отдавать

Сегодня расскажу о более простой, но не менее важной вещи – о техническом долге.

Григорий Петров

Опубликовано

/

     
     
[button color=4d61d7 icon=arrow-left-2 url=https://apptractor.ru/develop/grigoriy-petrov-trudnosti-proektirovaniya.html] Предыдущая статья [/button]

 

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

Откуда возникает технический долг

Как я рассказывал в прошлой колонке, направления развития программы часто взаимоисключающие – мы можем строить либо танк на гусеничном ходу, либо гоночный болид – и будет очень трудно на середине разработки сменить концепцию. Но часто возникают ситуации, когда прозревший заказчик (резкое изменение рынка или же “ой, кажется мы про это забыли”) требует таких серьезных изменений в программе, которые несовместимы с выбранной архитектурой. В таком случае есть два варианта:

  • Поменять архитектуру. Это правильно с точки зрения долговременного планирования, но потребует времени и денег. А заказчику часто бывает нужно внести изменения еще вчера.
  • Использовать “костыли”. Надеюсь, большинство моих читателей знают этот программерский жаргонизм. Для тех, кто не уверен, расскажу чуть подробнее.

Что такое костыли

1

Я не знаю где этот термин появился впервые, но сейчас, когда разработчики и менеджеры говорят про “костыли в коде”, они имеют в виде изменения, несовместимые с текущей архитектурой и приделанные к ней снаружи, только чтобы удовлетворить требования заказчика. Как человеку с больной ногой выдают костыль, чтобы он мог хоть как-то передвигаться, так и в программу добавляют код-костыль, чтобы хоть как-то выполнить задачу. Огромная разница заключается в том, что у человека нога рано или поздно заживет сама. А вот костыли, добавленные в код, сами никуда не денутся, и останутся в нем, формируя технический долг. Говоря иными словами, внося несовместимые с архитектурой изменения, разработчик “берет в долг” время разработки, обещая в будущем “сделать все как надо”. На практике это будущее никогда не наступает – у незнакомого с концепцией технического долга заказчика всегда есть срочная работа, которую надо делать вместо того, чтобы делать “непонятно что”. Технический долг копится, парализуя архитектуру программы – ведь он добавляет гораздо больше сложностей, чем обычные изменения, так как костыли, добавленные в код, “по живому” модифицируют архитектуру непредусмотренным способом.

Пример из жизни, которым я часто иллюстрирую костыли и технический долг на тренингах и консультациях – это полки. Обычные полки, которые крепятся к несущей стене перфоратором, дюбелями и шурупами. Предположим, у нас уже висят две полки и нам нужно повесить между ними третью. И тут, беда-печалька, ломается перфоратор. С точки зрения архитектуры, правильным решением будет починить перфоратор и сделать, как полагается. Но если полки надо кровь из носу повесить до вечера, то делается костыль – третью полку гвоздями или шурупами прикручивают к уже висящим двум. Торжественно при этом обещая, когда починится перфоратор, все переделать. Данное решение, кроме очевидных минусов меньшего поддерживаемого веса, повышает сложность системы и затрудняет ее изменение. Через два года, когда про костыль все забудут, пришедшие монтировать шкаф для встроенного холодильника сборщики мебели решат снять крайнюю полку… Ну вы догадываетесь, что будет. С техническим долгом все абсолютно то же самое – костыли копятся в коде, раскладывая по нему ловушки и мины, повышая сложность. Если не отдавать технический долг вовремя, то даже небольшая программа может в один далеко не прекрасный момент оказаться совершенно неподдерживаемой, потому что ее сложность за счет костылей уже давно вышла за пределы кошелька Миллера.

Как работать с техническим долгом

2

Первое и основное правило работы с техническим долгом – не упоминать о техническом долге о нем нужно знать. Чем больше участников разработки знает о техническом долге в проекте – тем проще следить за его объемом и выделять время на его устранение.

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

О техническом долге должен знать Team Lead, он же должен как-то фиксировать добавление технического долга в проект. Один из хороших способов – это ведение блога проекта, где Team Lead каждое утро записывает в свободной форме как вчера велась разработка проекта, какие были приняты решение, с какими сложностями столкнулись.

О техническом долге должны знать разработчики. Hindsight Bias (здесь и далее я буду использовать перевод “ретроспективное когнитивное искажение”, если кто знает перевод лучше – пишите) заставит их сопротивляться и хором говорить, что “это же очевидно и мы всегда об этом знали”, успешно забывая на следующий день. Один из хороших способов – это введение регламента о маркировке технического долга в коде, например, комментарием “//TODO:” или “//FIXME:”. Первое время тим лиду придется отслеживать корректное добавление и удаление таких комментариев, но в целом команда привыкнет к таким практикам довольно быстро.

Все надо обсуждать заранее

Человеческие инстинкты – забавная штука, доставшаяся нам в наследство от стайных животных. Или не доставшаяся – точно пока неизвестно. Большинству в коллективе трудно отказывать коллегам и обсуждать негативную информацию – считается, что это связано со стайными инстинктами, иерархией в стае и инстинктом обеспечения выживаемости группы. Но современное общество вообще, и команда разработки софта в частности, это совсем не стая обезьян. Диктуемое инстинктами поведение только вредит процессу. Как показывает опыт, отключить инстинкты “усилием воли” практически невозможно, но их достаточно легко обмануть, если знать о том, что они есть.

Один из самых простых способов обмана стайных инстинктов – это использование регламентов. Регламент, с которым согласились все участники процесса разработки, с точки зрения инстинктов становится “высшей сущностью” – следование регламенту инстинкты уже не воспринимают как угрозу стае.

К примеру, для работы с техническим долгом достаточно использовать простой регламент: если технический долг есть, то команда тратит 10% времени итерации (или любой другой оговоренный промежуток времени) на его устранение. Заранее утвержденный с заказчиком регламент позволяет довольно легко контролировать технический долг и не допускать гниение проекта из-за его накопления.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
1 Comment

1 Comment

  1. Konstantin Konopko

    26.04.2015 at 21:45

    Спасибо, это интересно!

You must be logged in to post a comment Login

Leave a Reply

Кроссплатформенная разработка

Google выпустил последнюю превью-версию Flutter

На Google Developer Days China была объявлена финальная девелоперская версия Flutter.

AppTractor

Опубликовано

/

Автор:

Судя по всему, Flutter Release Preview 2  – последняя версия перед выпуском стабильной версии Flutter 1.0, которая должна выйти в этом году.

Это уже шестая итерация почти за полтора года – первый анонс Flutter состоялся на Google I/O в мае 2017 года, а первая бета вышла в феврале.

В Flutter Release Preview 2 – поддержка фонового выполнения задач, уменьшение размера приложений до 30%, «pixel-perfect» приложения для iOS и расширенная поддержка этой системы.

Как говорит Google, на Flutter уже есть приложения Alibaba (Android, iOS), Tencent Now (Android, iOS) и Google Ads (Android, iOS).

 

 

Комментарии
Продолжить чтение

Новости

Интересные материалы: 19.09

У нас сегодня инструменты, уроки, курсы и исследования.

AppTractor

Опубликовано

/

Автор:

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Исследования

Новый отчет Developer Economics «Состояние нации разработчиков»

Компания SlashData опубликовала новый отчет из серии Developer Economics «Состояние нации разработчиков» за второй квартал 2018 года.

AppTractor

Опубликовано

/

Автор:

Это обобщенные данные опроса, который проходил весной, и на который ответило более 20,000 человек.

Ключевые выводы:

  • Data science и машинное обучение станут наиболее востребованными навыками в следующем году – 45% разработчиков хотят получить опыт в этих областях.
  • 33% разработчиков хотят изучать UI-дизайн, 25% – облачную разработку. Интерес к изучению других языков программирования меньше. Похоже, что разработчики хотят дополнять свои навыки, а не улучшать.
  • DevOps все более распространен – каждый восьмой в опросе работал над проектами из этой сферы.
  • У 40% есть интерес к роботам, но только 9% разработчиков работает над реальными проектами.
  • JavaScript остается самым популярным языком программирования:

  • Разработчики игр стали зарабатывать больше. Если в первой половине 2017 года только 29% опрошенных получали более 100 долларов в месяц от своих игр, то сейчас таких 48%.
  • Игровая разработка смещается в веб – в 2017 году 38% разработчиков игр работали для веба, а сейчас их 43%, в то время как доля смартфонов, планшетов и десктопов снизилась.

Весь отчет вы можете скачать по ссылке: http://sdata.me/DE2Q18DD.

Комментарии
Продолжить чтение

Новости

У Humble Book Bundle книги по разработке игр

В Humble Book Bundle новая распродажа – на этой неделе книги по разработке игр.

AppTractor

Опубликовано

/

Автор:

За 1 доллар вы можете получить руководства по Blender и SFML, учебник  по игровой физике, можете узнать основы Unreal Engine 4 и разработки игр на C++.

Заплатив 8 долларов вы получите еще 9 книг – про AI, OpenGL, VR, Unity, игровой дизайн.

Последний шаг – 15 долларов и еще 11 книг. Тут есть руководства по Vulkan, Godot, Swift, углубленные учебники по C++, Unity, Unreal.

 

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.