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% времени итерации (или любой другой оговоренный промежуток времени) на его устранение. Заранее утвержденный с заказчиком регламент позволяет довольно легко контролировать технический долг и не допускать гниение проекта из-за его накопления.

Григорий Петров
Комментарии Facebook
Продолжить чтение
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

Новости

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

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

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

/

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

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Мероприятия

Avito iOS Meetup Winter Edition: 2 декабря в Москве

Зима близко! Уже второго декабря состоится традиционный Avito iOS Meetup.

AppTractor

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

/

Автор:

Мы обсудим Data Driven подход, практическое применение Mach-O, lldb и dSYM, возможности расширения lldb, методологию Type Driven, а также концептуальные различия архитектур. В мероприятии примут участие представители Avito, Badoo, Туту.ру и Яндекс.

Программа:

  • Метрики всему голова
    Вадим Смаль (Avito)
    Поговорим о Data-driven подходе к разработке. Вадим продемонстрирует, какие метрики можно собирать, как они помогут быть эффективным и как следить за качеством разрабатываемой функциональности. Подробно рассмотрим, как замерять время компиляции отдельных фреймворков, размер приложения, время запуска приложения, CrashFree, OOM. Если вы до сих пор думаете, что метрики это только для менеджеров и аналитиков — будете приятно удивлены.
  • Расширения lldb
    Сергей Лем (Badoo)
    Все хотят писать код без багов. Но, к сожалению, пока что мало у кого это получается.И почти всегда отладка приложений занимает львиную долю времени при разработке.Поэтому важно иметь наиболее совершенные инструменты в своем арсенале и не тратить время не ерунду. Сергей Лем расскажет о том, как прокачать lldb при помощи  расширений на Python и сделать отладку приятнее и быстрее.
  • Mach-O, lldb, dSYM на практике
    Владислав Алексеев (Avito)
    В докладе речь пойдёт о бинарном формате исполняемых файлов Mach-O, об отладочной информации и объектных файлах. Рассмотрим, как работают брейкпоинты и символизация крешлогов. Поймем, когда и зачем нам нужны файлы dSYM, а в каких случаях их создавать совершенно не требуется. Также изучим случаи непрямого использования dSYM-файлов для анализа содержимого скомпилированного бинарного файла.
  • Type Driven Development
    Валерий Попов (Yandex)
    В докладе Валерий рассматривает строгую типизацию, которая может стать еще одним рубежом обороны надежного приложения от ошибок разработчика. На примерах будет показано, как дополнительная информация, переданная на этапе компиляции, поможет отловить ряд ошибок, не доводя систему до падения в runtime. Расскажет, что мобильный разработчик может почерпнуть из языков, которые ставят типы во главе процесса разработки.
  • Architecture overdose
    Стас Цыганов (Туту.ру)
    Стас Цыганов предлагает поговорить о разных архитектурах: как верхнего слоя, так и всего приложения. Речь не о баззвордах и сравнениях, у кого больше букв: цель —  понять, чем же они концептуально отличаются. Разберемся, почему появляется по архитектуре в неделю и почему в них нет ничего нового. Ну и в конце посмотрим, на что надо будет обратить внимание при выборе архитектуры следующего приложения.

Участие в мероприятии бесплатное, регистрация обязательна. Сбор участников: 12:00. Начало докладов: 12:30. Адрес: офис компании Avito, Лесная 7.

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

Новости

Эксперты выяснили, для чего Google форкнул Swift

Теоретически, добавление Swift позволит быстро портировать приложения c платформы Apple.

Леонид Боголюбов

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

/

На прошлой неделе Google на GitHub форкнул Swift, язык программирования, который создала Apple для разработки iOS/macOS/tvOS/watchOS приложений.

Эксперты полагали, что Google сможет вносить дополнения в открытый язык или использовать его для разработки внутренних инструментов для iPhone и iPad.

Однако последние коммиты в репозиторий Swift показывают, что Google работает над поддержкой Fuchsia OS. На GitHub вы уже можете посмотреть на “Hello World” приложение на Swift для. Fuchsia

Fuchsia: новая операционная система от Google

Fuchsia поддерживает Dart, C++ и Go. Теоретически, добавление Swift позволит быстро портировать приложения c платформы Apple.

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

AR стала частью реальности: что дальше?

Сегодня мы поговорим о важном событии в истории Apple (и это не запуск iPhone X) – мы поговорим о том, благодаря чему дополненная реальность (AR) стала чем-то большим, чем несбыточной мечтой маркетологов.

Джей лаб

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

/

Автор:

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

На сегодняшний день практически все эти препятствия исчезли. С помощью ARKit любой разработчик может создавать приложения в интерактивном формате, которые будут работать на новых iPhone, а также на некоторых предыдущих версиях (6 и выше) с iOS 11. Сотни миллионов пользователей iPhone, а также 100 миллионов устройств Android, которые теперь используют ARCore SDK от Google, означают, что настал переломный момент в переходе технологии AR на массовый рынок.

И как всегда, когда поведение потребителей начинает меняться, каждый хочет знать: «Что это значит для брендов? Как маркетологи могут использовать эту новую, интересную технологию для привлечения внимания потребителей?». С появлением оптимизированного оборудования у компаний появилось больше возможностей. Но как ими правильно воспользоваться?

Почему ARKit лучше альтернатив?

Ждите и наблюдайте

Помните, когда появился 3D Touch? Многие разработчики полагали, что он предоставит совершенно новый уровень навигации по мобильному приложению и что «долгое нажатие» станет таким же общепринятым действием, как «свайп». Но так ли это на самом деле? Вы, например, им пользуетесь? :) У меня есть доступ к этой функции уже более двух лет, и я только недавно обнаружил, что на обычном фонарике на iPhone есть три разных степени интенсивности, которые доступны только при глубоком нажатии на значок в Настройках. Теперь я постоянно использую уровень «низкого света» – но, согласитесь, два года – это совсем не быстрый уровень принятия новой функции.

То же самое касается AR. Все предсказания о том, что дополненная реальность войдет в повседневную жизнь пользователей, не подтвердятся, если на то не будет веской причины.

Конечно, демо-версия игры The Machines выглядит круто, но достаточно ли круто для ежедневного использования большим количеством юзеров? Для того, чтобы AR действительно стала частью нашей повседневной жизни, она должна создавать ценность, выходящую за пределы развлечения. Демо-версия приложения Главной лиги бейсбола выглядит гораздо интереснее, потому что информация о ходе игры и командах, отображающаяся прямо во время матча – это ценная информация, которую пользователи хотят видеть.

Сфера туризма и путешествий также готова к буму AR: приложения, которые накладывают указатели направлений на реальные улицы, отображают перевод надписей на реальных поверхностях, выдают информацию о достопримечательностях в непосредственной близости от них, – все они расширяют границы нашего восприятия мира. Мало кто знает, что до того, как Niantic запустили Pokémon Go, они создали Field Trip для Google Glass, которые уже поддерживали эту функцию.

Начните с малого – затем совершенствуйте, адаптируйте и переориентируйте

У нас есть отличная возможность, но все, что требуется, чтобы испортить ее – это плохая рекламная концепция или некачественное исполнение. Конечно, мы должны попробовать разные подходы и экспериментировать, чтобы в итоге все получилось, но я рекомендую начинать с малого. Для начала внедрите AR опыт, который меньше относится к вашему бренду и больше к вашей отрасли и аудитории. Например, ресторан может виртуально поместить на пустую тарелку вкусный, сочный бургер, но без логотипа на булочке и подписи «2 по цене 1». Для начала соберите данные о том, как потребители используют функциональность AR и как реагируют на нее.

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

Внедряйте лучшие методы и практики

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

На данный момент AR – это все еще «новая модная вещь», но стоит потратить немного своего времени и энергии, и мы действительно сможем понять, как мы можем эффективно ее использовать и устанавливать свои стандарты, создавая при этом новое рекламное пространство.

Джей лаб
Комментарии Facebook
Продолжить чтение

november

24novallday26What the hack?!

25novalldaySmart Taler 2017

25novalldayLadies Code: время технологий

30novalldaySmart Cars & Roads 2017

december

02decalldayAvito iOS Meetup Winter Edition

05dec18:3022:00Яндекс изнутри: глазами iOS-разработчика

08decallday09Кубок СTF России

09decallday10Games Gathering 2017

09decalldayЛекционный день по игровой индустрии

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

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

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

Наш Facebook

Популярное

X

Спасибо!

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