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

Дизайн и прототипирование

Будущее UX дизайна: за пределами экрана

Альберт Шум, вице-президент Microsoft по дизайну, рассказывает о будущем осмысленного дизайна в мире многих устройств – в переводе UX.PUB.

AppTractor

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

/

Автор:

Как масштабировать осмысленный дизайн в мире полном различных устройств

Нарушайте устоявшиеся шаблоны осмысленным дизайном

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

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

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

Создайте стол

Дизайн занял свое место за столом — теперь возьмите его дальше

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

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

Найдите свою модель работы

Статические системы не могут идти в ногу со временем — найдите свои дизайнерские модели

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

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

Выйдите на улицу

Идите и найдите новую точку зрения

Речь идет о поиске реальных потребностей и перспективы за пределами вашего привычного круга вещей. Ярчайшие моменты творчества часто находятся далеко от вашего стола. Идите на улицу и открывайте для себя что-то новое, потому что вдохновение стимулирует инновации.

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

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

Работа, которую надо выполнить

Зона дилеммы, в которой мы находимся. Желаемый уровень смысла — это то, куда мы стремимся

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

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

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

Будьте свободным радикалом

Refik Anadol, «Melting Memories» — результат совместного творчества машины и человека

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

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

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

Новости

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

Завершаем неделю анализом скриншотов, историями про разработку игр и дополнением форм с ИИ.

AppTractor

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

/

Автор:

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

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

Новости

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

У нас Firebase Summit и PWA, чатботы и секрет успеха GitLab.

AppTractor

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

/

Автор:

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

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

Медиа

Android Dev Подкаст. Выпуск 79. MVI против всех

Что такое MVI, и как его правильно готовить? Почему чистой архитектуры может не хватить, и где ее слабые места? MVI от Mosby это всего лишь MVP на стероидах? Новое заседание кружка архитекторов объявляется открытым!

AppTractor

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

/

Автор:

Что такое MVI, и как его правильно готовить? Почему чистой архитектуры может не хватить, и где ее слабые места? MVI от Mosby это всего лишь MVP на стероидах?  Новое заседание кружка архитекторов объявляется открытым!

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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