Tech Mist — Понимание технического долга (для нетехнических)
Нетехнические руководители проектов, заинтересованные стороны или члены команды, это для вас. Разработчики, которые боролись за приоритизацию технического долга, надеюсь, вы тоже найдете здесь что-то полезное. Я попытаюсь представить проблему растущего технического долга (технический долг) как недостаток коммуникации, а не как обременительный симптом разработки программного обеспечения. Конечно, технический долг сам по себе находится в рамках разработки программного обеспечения, но с техническим долгом доза делает яд; небольшая сумма не проблема. Решение должно быть там, где проблема: ее безудержное накопление. Почему это проблема общения? Потому что те, кто понимает природу технологического долга, часто не контролируют распределение бюджета или времени, а те, кто отвечает за распределение бюджета и времени, часто не понимают (и, следовательно, не могут обосновать выделение ресурсов) техническому долгу.
Корень проблемы
Технический долг — это накопление беспорядочного кода, который со временем накапливается в программном проекте до тех пор, пока весь раздел (или разделы) не потребуется либо переписать, либо интенсивно распутать. Это приводит к большим затратам усилий при незначительной или нулевой ценности для бизнеса. Хотя разработчикам программного обеспечения может быть сложно распутать технический долг, он также создает проблему коммуникации: донесение характера (и важности решения) технологического долга до людей, не являющихся техническими специалистами. Такие нетехнические люди часто являются заинтересованными сторонами или менеджерами, которые контролируют бюджет или сроки. Убедить их выделить время или ресурсы на задачи, которые не приносят немедленной пользы для бизнеса (за исключением расплывчатого обещания «все будет двигаться быстрее»), может быть невероятно сложно. Это — в сочетании с тем фактом, что пренебрежение техническим долгом часто усугубляет сложность проблемы (и, следовательно, увеличивает время и бюджетные ассигнования, необходимые для ее решения) — это то, что подтверждает мое мнение о том, что источником большей части технологического долга является плохая коммуникация, а не плохая связь. разработка программного обеспечения или плохое управление. Управленческий персонал, обвиняющий технический персонал в накоплении технического долга, в первую очередь не имеет смысла, как и технический персонал, обвиняющий руководство в том, что он не выделяет время, необходимое для его контроля.
Виды технического долга
Зачем компетентным разработчикам писать код настолько плохо, что его нужно переписывать с нуля?
Если бы мы знали тогда то, что знаем сейчас (неопытность)
Не путайте с использованием неопытных разработчиков!
Вызвано:
Разработчики, работающие на периферии своей сферы знаний; пространство, где вероятны ошибки, потому что лучшие варианты в настоящее время не известны.
Большинство разработчиков работают на самом краю своих знаний. Это происходит не из-за врожденной любви к обучению или внутреннего стремления к росту (хотя большинству разработчиков действительно нравится этот аспект), а скорее из-за того, что обычно мало причин писать код или создавать функциональность, которая уже существует. Помимо основных или фундаментальных функций, код должен быть написан для расширения возможностей программного обеспечения в мире, а не для дублирования существующих функций. По этой причине разработчики обычно должны работать над незнакомыми проблемами, используя знакомые инструменты. Как можно было бы ожидать из общего опыта, это означает, что сам процесс написания кода часто помогает разработчикам определить лучший способ решения проблемы, чем их первоначальный рабочий подход. Часто возникают споры о том, следует ли реализовать этот новообретенный лучший способ, поскольку рабочее решение доступно сразу. Приведение аргументов в пользу того, чтобы тратить больше времени на задачу, не добавляя немедленной ценности для бизнеса, — это основная проблема управления техническим долгом.
Как смягчить:
Написание «программных всплесков» — это распространенный способ позволить разработчикам проверить осуществимость решения и собрать некоторые знания, полученные при написании первого проекта. Всплеск — это, по сути, ограниченный по времени быстрый и грязный прототип, который должен работать только как доказательство концепции или выявлять фатальный недостаток в планировании или разработке идеи. Обычно шипы не разрешается включать в основной код из соображений политики, что позволяет избежать искушения тратить время на качество кода, а не на чистую функциональность. Если всплеск успешен, можно реализовать улучшенный второй вариант. Если всплеск не удается, идея пересматривается с нуля.
Опытные разработчики обычно имеют хорошее представление о качестве своей работы. Конечно, разработчики всегда хотят создавать безупречный, высококачественный код, но требуются компромиссы, когда фактор времени или бюджета является фактором (что почти всегда). Предоставление разработчикам возможности оценивать свою работу и установление порогового значения дополнительного времени на очистку, предоставляемого разработчику, не только поможет развить в команде полезную культуру откровенности, но и предотвратит потерю уроков, извлеченных из первых черновиков.
Просто нужно было перейти черту (целесообразность)
Вызвано:
Стремление выйти на рынок, внезапный разворот или любая другая причина, которая может привести к тому, что давление из-за нехватки ресурсов и коротких сроков усугубит друг друга.
Это наиболее распространенный тип технологического долга в проектах, которые в спешке доведены до MVP (минимально жизнеспособного продукта). Если идет дождь и вам нужно укрытие, можно посидеть под брезентом, пока он не спадет. Если вам действительно нужно немного поспать, а дождь не прекращается, вам может понадобиться палатка. Если вы проголодаетесь, вы пойдете искать еду. Когда вы замерзнете, вы можете собрать дрова и развести костер. Если вам повезет, вы сможете найти способы улучшить свои методы, когда ваши потребности будут удовлетворены, но вы вряд ли сможете сосредоточиться на строительстве надежного долговременного жилища, когда существует неизбежный риск проголодаться или заразиться голодом. холодный. Сама природа жонглирования конкурирующими интересами в условиях дефицита времени часто накладывает ограничения на то, в какой степени можно улучшить ваши методы удовлетворения этих потребностей. По этой причине нередко очень старые, целесообразные решения из ранней главы разработки программного проекта остаются на заднем плане годы спустя. Учитывая, что он старый, весьма вероятно, что он также является основополагающим. Если, когда у вас, наконец, появится немного времени, чтобы улучшить свое убежище, вы начнете складывать кирпичи вокруг своей палатки, а затем использовать шесты палатки для поддержки жестяной крыши, вы закрепите старое, хрупкое, целесообразное решение в своем улучшенном. . Без сомнения, причиной того, что вы это сделали, по-прежнему был непрекращающийся цейтнот. Чем больше слоев построено на скрипучих, дряхлых (но целесообразных) решениях, тем труднее их вытащить и улучшить. Вы никогда не сможете добавить черепицу на эту крышу, если не будете готовы провести несколько дней под дождем после того, как удалите старую систему.
Как смягчить:
Больше времени или больше ресурсов. Если они недоступны, вы не можете смягчить технический долг; все, что вы можете сделать, это попытаться контролировать ущерб. Это не обязательно плохо. Молодые предприятия часто имеют денежный долг по той же причине, по которой молодые системы работают на технологическом долге. В обоих случаях, однако, вы должны вернуть его с процентами.
Это было правильное решение в то время (устарело)
Вызванный:
Неспособность точно предсказать будущее.
При строительстве дома первое, что вы делаете, это закладываете фундамент. Бетонная плита подойдет для простого одно- или двухэтажного дома. По мере роста вашего проекта (или дома) идеально заложенный фундамент становится источником проблем; этого уже недостаточно, чтобы поддерживать ваше пятиэтажное здание, которое скоро будет построено, но необходимо поддерживать трясущиеся четыре этажа, которые вы уже возвели на нем. Это затруднительное положение не из-за плохого мастерства или даже плохого планирования — может быть множество причин, по которым было бы неприемлемо рискованно строить глубокий пятиэтажный опорный фундамент, когда вы только начинали. Просто вчерашнее идеальное решение сегодня является препятствием, а это значит, что нужно потратить время и усилия на замену этой плиты чем-то более подходящим. Также важно помнить, что планировать будущее очень сложно, когда продукт находится в зачаточном состоянии. Даже если бы нам дали дополнительное время и ресурсы, чтобы построить более прочную плиту для нашего дома, откуда мы знаем, что лучший способ приспособиться к будущему расширению — это увеличить количество уровней? Возможно, мы бы использовали этот лишний бетон, чтобы уложить растянутую плиту для размещения большого складского помещения, или, может быть, была бы вырыта более глубокая яма, а бетон использовался для строительства большого подземного бункера. Предсказывать будущее намного проще, когда для построения траектории можно использовать несколько точек отсчета; наш одноэтажный дом, ставший пятиэтажным, — это довольно четкий показатель того, что нам следует либо заложить фундамент, рассчитанный на десять этажей, либо сделать так, чтобы модификация фундамента в будущем была более легкой задачей.
Как смягчить:
Имейте план. Знание того, что запланировано на будущее, невероятно полезно для прогнозирования того, как текущие задачи могут быть расширены. Если вы заказываете окна для своего дома и вам нужно выбрать поставщика, знание планов на будущее (например, строительство теплицы на заднем дворе, желание ограждения из толстого стекла вокруг будущего бассейна или потребность в матовом стеклопакете на будущий верхний уровень), скорее всего, сообщит, каким стекольщиком вы пользуетесь. Точно так же знание того, как функция может быть расширена или с какими другими функциями она должна быть интегрирована, поможет принять архитектурные решения и поможет гарантировать, что наиболее расширяемое решение будет встроено с самого начала, продлевая полезность первого проекта.
Все было хорошо, пока мы не добавили все остальное (гниение кода)
Вызванный:
Растягивание цели чего-то слишком далеко за пределы его первоначальной компетенции.
Внесение слишком большого количества улучшений в что-то может превратить его в то, чем он никогда не мог себе представить. Активные кодовые базы необходимо постоянно модифицировать, добавляя новые функции или поддерживая существующие, а это означает, что идеальный микрокосм функциональности обязательно искажается несовершенными (хотя и работающими) дополнениями, которые первоначальный создатель не планировал. Представьте, что вы устанавливаете входную дверь в свой дом; стандартная дверь из цельного дерева с простой дверной ручкой идеально подходит для этой работы. Следующая задача: нам нужно уметь видеть сквозь дверь. Не беспокойтесь — просверлите отверстие в середине двери на уровне глаз лопатой и установите глазок. Следующая задача: нам нужно усилить стук гостей. Хорошо — завинтить дверной молоток. Далее: нам нужен отфильтрованный свет, чтобы он поступал в течение дня. Ну хорошо, мы можем установить панель из матового стекла в верхней половине двери. Мы можем переместить молоток вниз, чтобы он был немного ниже, но смотровое отверстие теперь должно проходить через матовое стекло. Немного странно, не идеально, но все работает. О, мы только что узнали, что иногда нам нужно оставаться в темноте. Хорошо — прикрепите шторку к верхней части двери с внутренней стороны. Опустите его и вырежьте в нем отверстие, где находится глазок, чтобы убедиться, что он все еще работает. Теперь бизнес-аналитики говорят, что глазок должен быть телескопическим. Ну ладно — прикрепите к глазку латунный выступ. Жалюзи теперь цепляются за него, но мы можем решить эту проблему, прорезав щель от нижней части жалюзи до отверстия, которое мы проделали для глазка в последнем задании. О, они хотят жалюзи в венецианском стиле? Это не сработает — ламели будут висеть по бокам двери, когда будет вырезана щель для телескопического глазка.
Этот сценарий может показаться безумным, но именно так часто звучат проблемы с гниением кода. На данный момент мы можем удовлетворить все требования с дверью из матового стекла с жалюзи, камерой слежения с зум-объективом и дверным звонком. В то время как большинство людей согласились бы с тем, что последние решения были четкими признаками того, что что-то в корне неправильно, указание точного шага, который должен был вызвать восстановление всей двери, является сложной задачей, особенно когда к смеси соображений добавляется высокая срочность. . Это также относится к подавляющему большинству проектов по разработке программного обеспечения. Обычно предупреждающие знаки игнорируются до тех пор, пока задача не станет невозможной или что-то не сломается.
По мере того, как несколько правильных решений накладываются друг на друга, они должны становиться все менее и менее совершенными, чтобы не фатально мешать функциям, с которыми они тесно сосуществуют. Думайте об этом как о отряде клоунов, залезающих в машину — первый с легкостью запрыгивает; последний извивается, корчится и заставляет себя войти, в то время как все остальные раздавлены и не могут двигаться.
Как смягчить:
Кодовая гниль — это факт жизни. Даже идеально разработанный код не застрахован. Если что-то идеально подходит для своей задачи, любое изменение в этом или в его назначении, наоборот, сделает его хуже. Поскольку частью цели большей части кода является расширение, код становится все более несовершенным по мере его обновления и улучшения. Хорошая архитектура и постоянная бдительность — единственные настоящие бастионы против гниения кода, и хотя они не предотвратят его появление, они гарантируют, что гниение кода будет меньше и его будет легче идентифицировать и устранить.
Как это сочетается
Усугубление технического долга — еще одна распространенная проблема. Даже в самых аккуратных и хорошо спроектированных проектах обычно есть часть, которую никто не хочет трогать. Часто это старый раздел, который слишком монолитный, чтобы его можно было заменить, но слишком ограниченный, чтобы делать все, что от него требуется. Иногда, в крайних случаях, будут другие классы или разделы кода, которые переводят другие задачи во что-то, с чем он может справиться. Его причуды или ошибки теперь являются ожидаемыми входными данными или выходными данными, поэтому их исправление может фактически представлять риск. В каком-то смысле это не так уж и плохо. Если проект и сам код работают достаточно хорошо, чтобы этот проблемный раздел не мешал, возможно, это просто небольшая отметка на очень аккуратном в остальном проекте. Вполне вероятно, что новую функцию можно придумать, оценить, разработать и внедрить, не затрагивая проблемную область. Вероятно, именно поэтому он постоянно теряет приоритеты — он не мешает, и можно сделать что-то получше, затрачивая время на его приведение в порядок.
Проблема заключается в том, что несколько слоев или множество общих разделов являются хрупкими, глючными, непоследовательными или неполными. Такая ситуация требует срочного решения проблемы и введения некоторых стандартов. Если вам нужно избегать частей кода в решении, которое вы разрабатываете, чтобы избежать других частей кода, у вас есть системная проблема, которая требует срочного внимания к техническому долгу. Код обычно не гниет до такой степени, поэтому такая ситуация почти всегда является результатом предварительной целесообразности.
Заключение…
…для разработчиков
Технический долг — это часть жизни, но управление им в рамках вашей работы должно считаться частью вашей роли, если все идет так, как должно быть. Если внешние факторы, такие как нехватка времени или отсутствие четкого плана, заставляют вас или вашу команду накапливать технический долг, обязательно сообщите об этом своему руководителю проекта (или его эквиваленту), чтобы он мог учесть дополнительный риск в своих оценках. Также убедитесь, что ваш руководитель проекта знает, почему накопился технический долг и каков путь его исправления.
… для руководителей проектов (или других нетехнических должностей)
Технический долг обычно накапливается сознательно, но должен быть погашен с процентами (причем сложными процентами). Система, перегруженная технологическими долгами, как правило, также работает медленно, что приводит к дополнительным затратам на ее игнорирование. Если ваша команда жалуется на технический долг, не ждите, что со временем он решится сам собой, без перекалибровки некоторых нагрузок на вашу команду. Накопление технического долга иногда является частью затрат на ведение бизнеса, но убедитесь, что вы делаете это намеренно и имеете план, когда он будет погашен. Чем дольше вы оставите его, тем сильнее он укоренится. Обвинение разработчиков не исправит это и не предотвратит дальнейшее накопление. Поощряйте своих разработчиков фиксировать накопление технического долга, чтобы вы могли принимать обоснованные решения о том, когда его решать.
