Управление техническим долгом

https://hackernoon.com/managing-technical-debt-1806424e7d40
  • Перевод
Екатерина Сазонова, переводчик-фрилансер и студентка «Нетологии», специально для блога перевела статью Carl Tashian о том, как продакт- и проджект-менеджерам справляться с техническим долгом.

image

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

Поддерживайте гибкость в нужных местах


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

Понимание того, что может быть гибким в программе, а что — нет, относится не только к текущим требованиям, но и к будущим. Вот почему так сложно создавать софт. Вы не просто поставляете свой технологический продукт, вы пытаетесь предсказать будущее. А будущее покрыто мраком, всегда есть риск преждевременной оптимизации. Придется сделать выбор: какой компонент фундаментален, а какой можно легко изменить.

Слово software (дословно «мягкое изделие», появилось в противовес «твердому изделию» — hardware) искажает суть понятия, потому что подразумевает гибкость во всем. Гибкость во всем — это идеал, к которому нужно стремиться. Однако, правда такова, что более строгую систему с очень тесно связанными компонентами построить намного проще. К примеру, можно утверждать, что в монолитном приложении элементы связаны между собой сильнее, чем в наборе микросервисов. Очевидное преимущество монолитного приложения — в его простоте. Хотите написать хоть строчку кода для приложения, основанного на микросервисах? Изучите сначала гигантский список требований к обмену данными, координации и доступности элементов системы.

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

Гибкость стоит дорого. Не могу даже сосчитать, сколько раз я создавал что-то с представлением о том, как изменятся в будущем требования, а потом обнаруживал, что менять нужно именно «неподвижные» части, а гибкие не обязательно должны быть гибкими. Сначала я думал, что мне просто не везет, но теперь я понимаю, что просто ошибался при планировании.

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

Рефакторинг для скорости


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

Прежде чем написать код, смиритесь с тем, что его придется выбросить


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

Работайте с тестами и анализируйте код


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

В компании должно быть принято проводить code review. Неважно, сколько тестов вы пишете, хорошо ли вы умеете рефакторить. Другие люди заметят моменты, которые вы пропустили. Ошибки. Баги. Опечатки. Да всё что угодно. Во многих компаниях по три пары глаз проверяют каждую строчку кода — считаю, это могло бы стать общим правилом.

Частота тестирования и проведения code review должна быть соизмерима с вредом, нанесенным проекту в случае провала. Исходный код требует более тщательной проверки, чем код интерфейса. Любое программное обеспечение, связанное с работой инсулиновой помпы, должно быть протестировано серьезнее, чем любое мобильное приложение. Можете себе представить команду, работающую над инсулиновой помпой, с лозунгом «Делай быстро и круши»? (мантра разработки Фейсбука и девиз Марка Цукерберга «Make fast and break things»).

Убейте плохо работающие фичи


Один мой знакомый инженер Ноа Торп как-то сказал мне: «Мы платим за каждую строчку кода каждый день». Чем меньше кода, тем меньше вы платите. Когда я работаю над проектом, мне важно, как работает каждая фича. Я регулярно собираю команду, чтобы решить, какие функции улучшить, а что убрать. Это значит временами признаваться себе в том, что фича, которая вам нравится, просто не работает.

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

Сведите зависимости к минимуму


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

Применять все эти методы проще, если они становятся общими принципами работы в вашей компании и для их использования создается благоприятная среда. Поддерживайте высокий уровень code review с запросами на включение кода (pull request). Продолжайте постоянно тестировать, поддерживая систему непрерывной интеграции (Continuous Integration). Ежемесячно обсуждайте основные фичи. Держите под рукой бумажные книги, которые рассказывают о правильных подходах, например, «Рефакторинг: улучшение структуры существующего кода» (“Refactoring: improving the design of the existing code”). И не забывайте их читать!

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

От редакции


Курсы «Нетологии» по теме:

Нетология 156,70
Университет интернет-профессий
Поделиться публикацией
Комментарии 16
  • +11

    Статья ни о чем. Советы как стать здоровым и богатым. Проверить выполняете ли вы что-нибудь или нет практически невозможно. Перевод тоже слабоват, перевод слова velocity как скорость вроде точен, но смысл сказанного искажает.

    • +1
      Не согласен. Статья содержит информацию, которую стоит доносить, повторять много раз в разных формах. От знающих не убудет, для незнающих и сомневающихся пойдёт только на пользу.
      • +5

        Давайте по порядку. Совет первый: «поддерживайте гибкость в нужных местах». Как проверить что это выполняется? Мало того что «нужные места» субъективный параметр, но не факт что вообще вычислимый.


        Рефакторинг перед добавлением фич и готовность выкинуть код — полезные советы.


        Про тестирование — спорно, зависит от проекта. Есть вещи которые тестировать дорого. Кодревью полезно, но это и так все знают.


        Сведите зависимости к минимуму это совет в духе «станьте богатым». Без конкретной методики смысла не имеет.


        По поводу фич — вне компетенции программиста.


        В итоге из 6 пунктов только два осмысленны и и не вызывают вопросов.

        • –1
          Совет первый: «поддерживайте гибкость в нужных местах». Как проверить что это выполняется?

          Предположить возможные изменения, думать на два шага вперёд. Если в конкретном случае изменений не предвидится — скорее всего затрачивать усилия на обеспечение гибкости в данном месте не нужно. Очень часто встречается не только у новичков, но и у про: переизбыток интерфейсов, слоёв, абстракций для обеспечения ненужной гибкости, что выливается в необходимость писать ненужные тесты ненужных абстракций и поддерживать этот бардак.

          Про тестирование — спорно, зависит от проекта. Есть вещи которые тестировать дорого. Кодревью полезно, но это и так все знают.

          Про тестирование — не спорно. С опытом понимаешь важность тестирования. Это как раз то, что постоянно подвергается сомнению. Видимо совет как раз для вас :)

          Про «все знают» уже говорилось, от вас не убудет.

          Сведите зависимости к минимуму это совет в духе «станьте богатым». Без конкретной методики смысла не имеет.

          Вы передёргиваете. Здесь нет никаких обещаний.

          В итоге из 6 пунктов только два осмысленны и и не вызывают вопросов.

          Тоже самое можно сказать про ваши аргументы :)
          • 0

            Вы не думали что излишние абстракции как раз от предположений что там будут изменения? Предположение вообще не надежный способ предсказания будущего. Как в одном фильме: “предположение — мать всех провалов”.

            • 0
              Ну я не знаю, я и мои коллеги — мы все делаем предположения. Думаем наперёд. Не знал, что это плохо. Может тогда и думать вообще вредно? :)
            • 0

              Про тестирование — не смешите мои тапочки. У меня было сильно больше одного проекта, где автоматическое тестирование было слишком дорогим занятием. Более того один проект буквально пришлось спасать потому что разработчики так заморочились над тем, чтобы код был тестируемым, что стало невозможно отследить какие фактические параметры передавались и как работала логика.


              А прямо сейчас у меня хобби-проект — Разработка мода к игре. в Нем автотесты написать вообще невозможно.

              • +1
                Поддерживаю! Разговоры про авто-тесты это как поговорка, что лучше быть здоровым и богатым, чем бедным и больным. Вроде правда, но достижимо не для всех.
                • 0
                  Давайте так. Тесты улучшают качество кода и улучшают качество и скорость сопровождения. Не знаю как у вас, у меня этот тезис подтверждается раз за разом. Тест пишется один раз, потом постоянно окупается. Да, ничего не бывает бесплатно. Но тесты — это хорошая и правильная инвестиция. Мой многолетний опыт это подтверждает. На гитхабе любой уважающий себя и других разработчик обязательно напишет тесты к библиотеке.

                  Ваш один неудачный опыт вообще не показатель, уж извините меня. А фломастеры «нравится/ненравится писать тесты», обсуждать не очень интересно. Конечно, бывают исключения, но вы на этих исключениях строите свои выводы, что вообще-то неправильно.

                  Это как спорить с утверждением, что надо вести здоровый образ жизни, приводя в пример условия, где это невозможно, например, боевые действия. И после этого говорить, ну… можно и не вести здоровый образ жизни, так тоже нормально. Речь идёт о полезных советах, а не про все-все условия и обстоятельства в жизни.
          • 0
            Как, на ваш взгляд, стоило перевести слово velocity в данном случае? Спасибо
            • 0

              А вот не знаю честно говоря. Можно поступать как финансисты и не переводить специальные термины. У них факторинг, а у программистов велосити.

        • 0
          Про тестирование — спорно, зависит от проекта. Есть вещи которые тестировать дорого

          Что тестировать дорого — можно тестировать реже:
          Частота тестирования и проведения code review должна быть соизмерима с вредом, нанесенным проекту в случае провала


          По поводу фич — вне компетенции программиста

          Ну, кагбэ, да:
          Carl Tashian о том, как продакт- и проджект-менеджерам справляться с техническим долгом

          • 0

            Речь разве не про автотесты? Или ещё есть люди которые выпускают код в прдакшн без проверки вручную?

          • +3
            Где про технический долг-то? Одна вода.
            • 0

              Здесь это есть с точки зрения "не лезь в (технические) долги, если это не очень надо". Конечно, статья очень общая, практически обзорная. Не книга, не справочник, не учебник — одним словом, статья. Однако, пока читал, не заметил здесь вопросов, не относящихся к техническому долгу. Я с другой планеты, да?

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

            Самое читаемое