Итак, менеджер попросил пофиксить баг…

в 19:59, , рубрики: баги, отношения с менеджерами, Программирование, Управление продуктом, управление разработкой, устранение ошибок
Итак, менеджер попросил пофиксить баг… - 1

Вы были здесь прежде. Ваша программа элегантна. Вы использовали точно требуемое количество абстракций. Ваши модули безупречно модульные. Ваша система имеет дело с внешним миром через продуманные интерфейсы и не имеет никакой прямой зависимости от внешних систем. Ваши тесты пройдены безукоризненно. Ваш отчёт о покрытии тестами кода требует целую минуту для загрузки. 97% это значит…

Жизнь прекрасна. А затем происходит нечто.

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

Менеджер сообщает, что жалобы от пользователей идут потоком. И он спрашивает: «Можешь ли посмотреть?».

Конечно, вы можете посмотреть. В конце концов, именно вы создали этот продукт. Это, скорее всего, вина кого-то другого. Но вы собираетесь устранить ошибку. Это — часть работы своего рода «кризисного» сотрудника, которым вы и являетесь.

Вы вытягиваете Git hash из самого последнего релиза и копаетесь в журнале изменений. Вы обновили библиотеку HTTP-запросов до самой последней версии в последнем релизе. Это и так откладывалось довольно долго. Вы можете вспомнить коммит, который привёл к этому. Это был хороший день.

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

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

Вы знаете, что кто-то, не вы, допустил ошибку. Такова жизнь.

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

Ну, конечно! Вы уже рассмотрели все возможности.

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

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

Итак, действия спланированы:

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

Всё элементарно, Ватсон!

«Замечательно», — говорит вам менеджер. «Сколько по-твоему это потребует времени?».

Вы знаете ответ. Некоторые думают, что технические специалисты неспособны оценить время. Но вы-то точно не из таких специалистов.

«2 недели» — без запинки отвечаете вы. «Зависит от того, как быстро будет принят запрос на включение кода и как быстро эксплуатационный персонал выдаст новую сборку».

Лицо менеджера на глазах белеет. «2 недели? 2 недели?!». Он продолжает повторять эти два слова, как будто они могут изменить что-то. Но вы остаётесь спокойным. Менеджеры, как известно, слабые ребята, могут кипятиться. Не стоит вам волноваться из-за этого.

«От нас уйдут наши пользователи! Они ничего не покупают, потому что не видят, что происходит с их корзинами! Мы же компания, торгующая через интернет! Это невозможно!».

Вы наблюдаете, как он проходит 5 этапов отчаяния. Вы ждёте, пока он, наконец, согласится. Но это не происходит. Он, кажется, пытается прессовать.

«Неужели нет какой-либо возможности исправить быстрее? Ну, может быть, что-нибудь временное? Ну, подумай! Это очень важно!».

«Хорошо», — говорите вы, опускаясь на ваше вращающееся кресло. «Дай посоображать».

Вы уступаете ему немного. Может быть, тогда он оставит вас в покое. У вас много других дел, вы это знаете.

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

О! Вы нашли его. Есть незадокументированный способ войти в программу анализа JSON и заменить её вашей собственной разработкой!

Но подождите. Это может быть опасным. Здесь программный интерфейс приложения является непубличным. Возможно, неправильно поступить с ним так, как вы предположили. Вам не хочется идти на это. Что если в следующем выпуске ошибка будет устранена? Тогда придётся проделать всё это заново. Есть желающие? Хотя это быстрее, чем поддержание вашей собственной, непротестированной, ветви библиотеки. Опять же, это опасно.

Нет!

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

Вы быстро входите в закуток менеджера: «Я говорю тебе — нет! Здесь нет чистого способа сделать это и я не могу полагаться на небезопасные хакерские трюки. Извини.»

Он реагирует ожидаемо.

«Ты говоришь, что есть способ решить проблему, но не будешь это делать, поскольку способ, оказывается, нечистый? Наши пользователи буквально кричат на нас, угрожают уйти к нашим конкурентам, а ты не желаешь устранить баг, потому что способ нечистый?!»

Вы теряете контроль над собой.

Что этот парень знает о проектировании программ? Вы создали фантастические миры из ничего, кроме битов. Великолепно масштабируемые системы, которые могут противостоять DDoS-атакам всех компьютерных хакеров бывшего советского блока, созданы вами. Вы — художник, а компьютер — ваш холст. Вы прочитали книгу «Чистый код» Роберта Мартина столько раз, что знаете её лучше, чем даже собственный GitHub-паспорт.

«Да!», — срываетесь вы. «Я не замараю нашу базу кода этим дерьмом! Я потратил месяцы своей жизни на создание этого дворца! В каждой строке кода запечатлелись моя боль и кровь! Единственная причина по которой здесь, вообще, что-то работает — в том, что всё делалось не благодаря вам, а несмотря на вас. Именно такие, как я, обеспечивают работу всех этих программ и именно такие, как я, должны будут долго приводить в порядок всю эту мешанину, после того как вы и ваши „бизнес-процессы“ уйдут!»

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

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

Вы берёте чашечку кофе и смотрите, где бы присесть.

И тут вы видите его.

Самого почтенного по годам специалиста в нашей компании.

Этот человек относится к крутым, бескомпромиссным специалистам типа «я-могу-написать-компилятор-за-5-минут». Он был хакером ещё до того, как появились хакеры. Вы желаете быть похожим на него. Он отчасти похож на мага Гэндальфа из книг Толкина. Все его уважают и боятся одновременно. Но он добр и всегда выручает детей. Он точно захочет услышать, как вы поставили этого менеджера на место. В конце концов, он — один из представителей вашего цеха.

И вы садитесь рядом с ним. Он не спеша пьёт свой кофе и читает что-то вроде «Абстрактные типы данных в Haskell».

Да. Просто коллега, чтобы поговорить.

Вы излагаете ему свою эпопею. Он терпеливо выслушивает. Он кивает и задаёт несколько вопросов. Его тело спокойно и расслаблено. Он был здесь прежде. Вы можете видеть это в его глазах.

Вы, наконец, закончили.

Это было утомительно.

Вы сбросили груз с плеч.

Он смотрит в раздумье, как будто тщательно подбирает слова.

Вы ждёте, что он громко рассмеётся. Он воскликнет: «Да, мой мальчик!» — а затем вы выпьете ещё по чашечке кофе вместе. Он развлечёт вас историей похожей взбучки, которую он задал бестолковому менеджеру сто лет назад.

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

Это — сентиментальность, хотя она имеет значение.

Вы ждёте…

И ещё ждёте, и ещё…

Он смотрит вам прямо в глаза. Его взгляд проникает в вашу душу. Долгие годы разборок с машинами придали его глазам твёрдость. И он несёт в себе завораживающую мощь. Вы не можете отвести взгляд.

Он произносит совсем немного.

«Ваша работа состоит не в том, чтобы пить кофе и уклоняться от написания кода. Ваша работа в том, чтобы делать программы, которые работают.»

Затем он уходит.

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

Вы подвели людей, которым вы обязаны больше всего. Ваших клиентов.

И вы идёте назад к вашему компьютеру. Вы быстро взламываете программу, затем удаляете последний релиз.

Вы извиняетесь перед менеджером: «Извини, друг, дела вышли немного из-под контроля». Он говорит, что всё в порядке. Всё хорошо, что хорошо кончается.

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

Автор: LukinB

Источник

Поделиться новостью

* - обязательные к заполнению поля