Переводим на 50+ языков, делаем видео IT-компаниям
89,34
рейтинг
28 марта 2013 в 11:58

Разное → Технический долг разорит вас. Если вы позволите, конечно перевод

Переведено в Alconost Translations.

imageНедавно проект, над которым я работал, наконец запустился. Ладно, перезапустился. Речь о небольшом простеньком приложении для айфона Postography, которое позволяет рассылать бумажные открытки с картинками и текстом с вашего айфона. Отличный и, вроде бы, несложный проект, правда? Приложение, на создание которого не должно было уйти много времени.

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


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

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

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

Это случается даже с передовыми технологическими компаниями. Возьмите хотя бы RIM. Помните, они выпустили планшет без почтового клиента? Помните, как они тихо топтались на месте целую вечность, пока iOS и Android ушли вперед, оставив BlackBerry в кильватере? Их неудачи не были обусловлены выбором дизайна или сознательными решениями руководства. Они случились из-за огромного технического долга, на избавление от которого у компании ушли годы.

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

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

Так как же стартапам избежать этой незавидной судьбы?

Конечно же, критично важно нанимать правильных людей. Помогает также парное программирование c использованием модели «главный/ проверяющий», которую я особенно люблю. И мне всегда казалось, что технические оценки — хорошая идея: пускай несколько опытных специалистов потратят неделю на аудит вашего кода и архитектуры, один раз в самом начале разработки и еще раз где-то в середине процесса. Компания, на которую я работаю, проводила такое один или два раза, но, к сожалению, технические оценки пока не стали обычной практикой для отрасли.

Что можно сделать, если вы уже накопили серьезный технический долг? Прежде всего, вытащите голову из песка и признайте, что у вас есть большая проблема. Дальше — прекратите копать. Перестаньте добавлять новые возможности и приведите все к полустабильному состоянию, чтобы увидеть, что у вас есть и чего нет. Потом постарайтесь определить, можно ли не перестраивать ваш метафорический дом, а лишь заменить его фундамент (даже при том, что работавшие ранее вещи снова сломаются в ходе реконструкции, что всегда очень раздражает), или же придется бросить все и начать новое строительство. Каждое из этих решений может оказаться самым лучшим и быстрым.

Но больше всего прислушивайтесь к своим разработчикам. Если вы наняли правильных людей, то они хотят чистого, расширяемого, масштабируемого кода так же, как и вы. Было почти больно просматривать доставшийся нам исходный код Postography. Сейчас я чувствую себя так, будто мы провели операцию, которая не только спасла жизнь жертве страшной автомобильной аварии, но и дала ей возможность стать олимпийским атлетом. Никогда не поздно спасти ваше приложение, но чем раньше вы начнете — тем легче это сделать.
Автор: @alconost John Evans
Alconost
рейтинг 89,34
Переводим на 50+ языков, делаем видео IT-компаниям

Комментарии (13)

  • +7
    Парное программирование и модели «главный / проверяющий» самостоятельно не помогут избежать технического долга.
    Очень редко технический долг вина непосредственных разработчиков, обычно ответственны за это руководители разных уровней, далекие от технической реализации.
  • +5
    Технологический долг, как правило, есть всегда, вопрос только в его размере. Адекватные разработчики просто тихо рефакторят проблемные места и кажется что все под контролем.

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

      Системная проблема возникает, когда менеджмент оторван от технологии и эксплуатации слишком сильно. Тогда менеджмент не видит эксплуатационных проблем или не адекватно оценивает их как «быстренько исправьте и побежали дальше». Если одновременно менеджмент должен гнать сроки, то отсупать разработка может только за счет качества — потому что его не видно. :) Тогда возникает кризис — разработка считает, что все плохо из-за менеджмента, а менеджмент думает, что разработка вечно ноет, а надо бежать.
      • 0
        Очень точно сказано.

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

        Вот пример из жизни: Продукт запущен в срок, но в тот момент, когда менеджмент объявляет, что собирается запустить продукт именно в этот срок, разработчики с опытом хватаются за головы и, в кои-то веки, становятся инициаторами многочисленный собраний по этому поводу. В результате всех споров и недопониманий часть из них просто уходит.
        Потом несколько месяцев после запуска царит полный [цензура] и разработчики «без перерыва на сон» вносят тысячи правок на живую, чтобы «заработало хоть как-то». А потом менеджмент бьет себя в грудь и говорит «Ребята, мы сделали!», а ребята находятся в «активном поиске» новой работы, потому что никто не хочет поддерживать «это», потому что понимают, что развивать «это» нереально. Нужно практически в буквальном смысле делать все заново. А на это, конечно, никто ни времени, ни ресурсов не даст. И менеджмент искренне недоумевает, почему разработчики недовольны и уходят. Ведь «Все работает! Чуть-чуть тут допилить, чуть-чуть там, а так все работает!», а на их место приходят новые, и первое время с легкостью выносят приговоры о компетентности предыдущих, потому что еще не понимаю куда попали.

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

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

    Вы меня опередили :)
  • +3
    Мне кажется, ответственность за технологический долг несут две стороны:
    1. Технари, которые реализуют неоптимальные решения
    2. Менеджеры, которые не дают времени/ресурсов сначала на наём хороших сотрудников, потом на более тщательную реализацию, а затем не признают и не принимают вовремя необходимость доработок.

    Поэтому, парным программированием и разработчиками этот долг не закрыть.
  • +2
    Оптимальной работа будет тогда, когда руководитель ПО и менеджмент знает когда можно допустить технический долг и когда его нужно отдать. Программисты же часто поступают непрагматично с точки зрения бизнеса, например, пишут уж слишком чистый код.
  • 0
    По-моему, пример RIM в качестве иллюстрации опасности технического долга не годится и только вводит в заблуждение. Особенно в сочетании с советами насчет «парного программирования», т.к. провал RIM случился вследствие стратегических ошибок руководства компании.

    Когда вышел первый iPhone, стало очевидно, что это гаджет следующего поколения с операционной системой другого типа и революционным интерфейсом. Но руководство RIM не ожидало быстрой потери рыночной доли и слишком долго продолжало сидеть на старой базе. В отличие от супергигантов, вроде Microsoft, Rim — относительно небольшая монопрофильная компания, у которой почти нет шансов догнать лидеров, засидевшись на старте. Из-за схожей причины неуспевания HP провалила запуск своих гаджетов на довольно хорошей WebOS.
  • 0
    Нанять правильных людей, тоже не достаточно для решения проблемы, ибо некоторые, даже очень зеленые, программисты считают что все делают «правильно».
    • 0
      И еще хуже, что они считают «неправильным» сделанное другими. «Все переписать!» — первый признак юного разработчика
  • –1
    Вася и Петя одновременно начали писать один и тот же продукт.
    Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
    А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
    Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
    Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
    У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
    В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
    (с) bash.im/quote/420672
    • 0
      Кто-то злой поставил минус, а между прочим картина весьма реалистичная. Едва ли не большинство доминирующих продуктов сделаны криво и косо, все ругаются, но терпят. А тщательно продуманные и вылизанные архитектуры умирают из-за
      — «пока добежим, все вкусное съездят» — продукт готов, а рынок занят.
      — инвестор не вытерпел, деньги кончились. не у каждого есть терпеливый и верный инвестор.
      — заплутали в идеалах. сделали все правильно, не учли нюанс, переделали еще раз правильно, еще раз не учли, еще раз переделали. запутались, умерли.
      — изменились требования. «пока расчет производился, объект расчета в норке скрылся»
  • 0
    Технический долг совершенно нормален для любого живого проекта. «Девелопмент в рассрочку» — мы это называли так. Ценность получим сейчас, а проблемы отложим на потом.

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

    Сам долг лучше бы мерить в количестве постоянных (recurrent) проблем, а не субъективном качестве кода. Я несколько раз наблюдал (и организовывал) смену команды разработчиков на проекте — и для всех живых проектов, абсолютно ВСЕГДА новые разработчики характеризовали старый код как «клоаку». Даже если команду сменить повторно — третья команда охарактеризует как «клоаку» творчество второй. :) Был даже пример обратной передачи — угадайте, что говорит первая команда про «что вы тут без нас наворотили?» :)

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

Самое читаемое Разное