Фича фриз что это
Не баг, а фича. Что это значит и откуда появилась эта фраза?
Велик и могуч язык программиста. Иногда этот язык наполнен таким количеством сленговых слов, что его трудно понять не то чтобы простым пользователям, а даже молодым и начинающим программистам. Сегодня мы разберем, что значит довольно популярное выражение : « Э то не баг, а это фича» и когда оно применяется.
«Не баг, а фича!»
Что так ое «баг» в программировании?
Это довольно частый вопрос, потому что слово «баг» не всегда связано с программированием. В программировании «баг» — это ошибка в программе или в приложении, которая приводит к тому, что программа или приложени е не работают как следует. Само слово «баг» происходит от английского слова «bug». По причине воздействия бага на программу мы получаем продукт, при работе которого происходит нежелательный конечный результат.
Баг имеет широкую градацию по способу собственного возникновения и влияния на конечный продукт. Сегодня мы не будем на этом останавливаться, отметим лишь, что все возникающие баги объединя ю т следующие свойства:
Что такое « фича » в программировании?
Фича в программировании — это некая новая функция или особенность программы, которая ранее не была о г оворена, но в результате не нарушает функциональность программы, а приносит какое-то дополнение в ее работу. Фича происходит от английского слова «feature». Ее цель — улучшить характеристики программы или просто привлечь внимание пользователей своей необычной функцией.
Понятие «фича» существует не только в программировании, оно уже часто употребляется и в обыденной жизни. К примеру, фичами в быту именуют нестандартные функции или дизайн какого-нибудь устройства.
Фича в программировании — это контролируемый результат, который создается специально руками программиста, чтобы улучшить разрабатываемую программу или просто удивить пользователей или заказчика. Фичи часто не нужно исправлять, потому что они очень органично приживаются с самой программой.
Мы можем предположить, что такое выражение может употребляться в качестве оправдания разработчика перед заказчиком, когда тот обнаружил баг в программе. Но часто это совсем не так.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Не пишем код целый месяц и нам нормально
Праздничные дни для Додо Пиццы — дни высокой нагрузки. К таким дням мы готовимся заранее и заводим специальные правила.
Самое жаркое время — в декабре: много корпоративов, заказы становятся больше, но и прибыль выше. Во многих городах плохая погода — где-то снег только выпал и дороги не расчищены, где-то очень холодно. Всё вместе это создаёт нагрузку и на IT, и на бизнес. От нагрузки может сломаться что угодно: то очередь задач переполнится, то печь выйдет из строя. Чтобы быть готовыми, мы регулярно проводим нагрузочные тестирования, повышаем закупки ингредиентов, распределяем заказы по пиццериям и много чего ещё.
Для мобильных разработчиков конец года раньше тоже был особенным: с 23 по 27 декабря App Store закрывался на рождественские праздники, приложения не проверялись, опубликовать что-то было невозможно.
Расскажу, как эти ограничения влияют на разработку, какие ошибки мы совершили в прошлые годы и что меняется в расписании. Возможно, что-то из практик пригодится и вам: подсветит риски, поможет договориться о код-фризе с бизнесом.
Опыт прошлых лет
Так получилось, что прошлые декабри проходили у нас довольно стрёмно. Например, пару лет назад мы делали конструктор комбо и зарелизили его в в начале декабря. Оказалось, что фреймворк Dip переполнился от количества связей в DI и приложение стало очень долго запускаться. На новых телефонах это не было заметно, а вот на стареньких iPhone 5 и 6 оно даже не успевало стартануть за 30 секунд!
Мы подозревали, что DI может сломаться, но не подозревали, что это произойдёт так внезапно. Переделать описание всех зависимостей перед последним релизом сулило ещё большие потери, чем могли быть в тот момент. Подробно рассказывали об этом в статье «Бардак на старте: постмортем на скорость запуска iOS-приложения».
На следующий год мы сделали вывод и в начале ноября вспомнили, что надо проверить ключевые показатели заранее. Увы, даже это оказалось поздно для бизнес-планирования: в начале декабря должен был выйти крупный релиз сразу от трёх команд:
в Сыктывкаре запускали заказ через приложение в ресторане, чтобы проверить бизнес-процессы. Отменить было нельзя, потому что маркетинг уже подготовил все активности;
в Великобритании для пиццерии нового формата сделали другой флоу выбора адреса;
начали оповещать пользователя о высокой нагрузке на пиццерию и предлагали сделать отложенный заказ. Фича хорошая — помогает бизнес-процессам и снижает негатив клиентов. Плохо было только то, что выпускали её в середине декабря — к этому времени она была очень нужна и был только один шанс зарелизить. Если в тестировании на продакшене оказалось бы, что в процессах пиццерии что-то идёт не так, то поправить уже ничего не смогли бы.
Вроде бы изменения точечные и касались региональных тестов, но поздний запуск сыграл против нас.
Во-первых, выяснилось, что пиццерия в Сыктывкаре находится в подвале и там плохо ловит связь, поэтому нужно было срочно менять способ загрузки изображений, экономить трафик и переходить с JPEG на более современный формат, что влияет сразу на все приложения. Без этого тестировать в ресторане нечего, приложение у людей совсем не показывает картинки и они не делают заказы.
Во-вторых, флоу Великибритании сильно влияет на старт приложения, хитро переиспользует существующие фреймворки, из-за скорости разработки решение получилось запутанным, в январе пришлось переписывать.
В третьих, визуализация нагрузки на пиццерию была написана в спешке и покрывала лишь самый простой случай, поэтому наше решение задачу решало лишь частично.
В итоге тот релиз вышел не очень стабильный и в декабре мы выпустили аж три хотфикса, а потом ещё в январе доделывали и рефакторили.
Стало понятно, что начало ноября — слишком поздно для планирования. Про Новый год нужно думать в конце сентября, до начала четвёртого квартала.
Планируем даты и размер релизов. Релиз-фриз
Давайте посмотрим на календарь и поймём, какие критичные даты у нас есть. Начнём с конца декабря.
С 23 по 27 декабря нельзя релизить приложения в App Store, в Америке рождество. Apple заранее рассылала письма и предупреждала, что сроки сдвинутся. Для многих компаний Новый год — важное время, все хотят закончить свои задачи, а это значит, что неполная неделя с 20 по 23 будет сложной для ревьюверов и время на ревью может увеличиться.
В этом году Apple перестала уходить на рождественские каникулы, тем не менее, ревью может быть медленнее обычного.
Это не изменило наши планы, нагрузка на пиццерии не зависит от Apple, но напряжение от сроков стало меньше.
По статистике, каждый наш релиз требует хотя бы одного хотфикса. Значит, нужно на неделе с 13 до 15 декабря сделать последний релиз, чтобы успеть исправить, если что-то пойдёт не так.
Проблема не только в том, что мы иногда косячим, но и в том, что в мобильной разработке релизы катятся медленно и фидбэк с продакшена может прийти слишком поздно:
если релиз раскатывается постепенно, то за неделю получим обновление у 40% людей;
если релиз был открыт на 100%, то за неделю приложение обновится лишь у 70% людей;
через месяц обновятся только 90%, а оставшиеся 10% растянуты на годы, хвост старых версий очень долгий.
Получается, что если мы хотим к Новому году закончить фичу и сразу запустить рекламу на неё, то, чтобы не нагружать саппорт вопросами «почему у меня нет такого функционала?», стоит раскатить нужный функционал хотя бы за 2-3 недели до запуска и спрятать его за фича-тоглом до нужного момента.
С другой стороны, если столкнёмся с проблемой, то остановить релиз тоже не получится: приходят новые пользователи и они всегда получают последнюю версию, даже если в ней есть проблемы.
Есть и другие причины отодвинуть релизы подальше от конца декабря и праздников в январе:
некоторые баги воспроизводятся только в редких ситуациях, за полторы недели пользователи достаточно повзаимодействуют с системой, чтобы можно было считать, что все критичные редко встречающиеся баги всплывут и будут исправлены до Нового года;
некоторые проблемы с надёжностью могут иметь накопительный эффект и стрельнуть только при длительной работе под нагрузкой или без перезапуска серверов (как, например, медленное, но уверенное «выжирание» памяти или ЦПУ), поэтому важно посмотреть на работу системы вдолгую, прежде чем со спокойной душой уходить на каникулы;
Если мы хотим, чтобы система прожила без нас полторы недели в январе, то давайте посмотрим, как она проживет полторы недели в декабре хотя бы без релизов.
Исходя из этого, мы приняли несколько правил.
С 1 декабря по 15 не должно выходить очень крупных изменений. Если изменений будет много, то за один хотфикс можно и не успеть всё поправить или изменения не дойдут до пользователя.
Все фичи, которые выходят в декабре, должны быть спрятаны за фича-тоглом и уметь отключаться. У нас есть механизм фича-тоглов, поэтому некоторый функционал можем отключать без релиза. В худшем случаем мы останемся без фичи, но люди смогут заказывать.
Увы, некоторые изменения слишком дорого или невозможно тоглить, например инфраструктурные изменения (переход на Tuist). Получается, что зарелизить их нужно ещё раньше, чтобы успеть исправить до того, как начнётся декабрь и высокий трафик. Крайний срок больших изменений — середина ноября.
У бэкенда процессы немного другие: нет ревью от вендора, а обновление происходит сразу для всех, поэтому релизы можно катить чаще.
В итоге наш график сейчас такой:
15 ноября — последний релиз инфраструктуры в мобильной разработке, когда не можем оттоглить наши изменения;
29 ноября — последний срок большого релиза, все фичи должны быть затоглены. Если нашли баг, то нужно срочно катить фикс;
6 декабря — последний мажорный релиз бэкенда;
13 декабря — последний возможный релиз небольшой фичи.
До изменения режима работы App Store наш график релизов выглядел так, как на картинке выше. По нему видно, что с середины ноября мы не можем катить большие фичи, а это половина квартала. Такое очень важно учитывать при планировании: поменьше взять в работу, запланировать релиз важных фич пораньше. Релизить можно до 13 декабря, но размер и ценность релизов должны плавно снижаться, чтобы сохранять правильный темп, не торопиться, не косячить и в итоге не падать.
Как «продать» код-фриз бизнесу и разрулить конфликты
Неожиданным оказалось то, что продать код-фриз бизнесу несложно: показываете риски, обсуждаете возможные потери, требуете от аналитиков прогноза по доходу от фичи, составляете risk-reward, планируете сроки и как-то быстро приходите к договорённостям.
На деле намного сложнее продать код-фриз программистам: появляются десятки вопросов, уточнений, что можно и что нельзя сделать.
Релизы декабря лидеры направлений и SRE одобряют в ручном режиме. Покажу на примере.
Команда хочет выпустить фичу, которая будет рассказывать о нашей новой программе лояльности и персональных акциях. Виджет должен появиться на экране меню и визуально изменения небольшие.
Сине-фиолетовая плашка в центре экрана — герой примера
Уточнив у разработчика, понимаем, что для добавления простой плашки пришлось переверстать весь экран меню (там накопилось теходолга, нужно было исправить), при этом мы добавили анимации на обновление экрана, а они могут конфликтовать и ломать приложение. Это старт приложения, т.е. критичный путь пользователя до заказа, и если что-то пойдёт не так, то мы заденем большую часть пользователей. Затоглить такой рефакторинг сложно, он только повысит шансы что-то упустить. По-хорошему такая фича должна чуть дольше «помариноваться» в dev-ветке среди тестировщиков и разработчиков.
С другой стороны, мы рассказываем про бонусную программу. Это хорошо для возвращаемости клиентов, но не несёт прямого профита, эффект от фичи будет заметен не сразу.
При этом времени у нас мало: чтобы закончить фичу, нужно отложить все остальные дела и, возможно, подключить другую команду. Не только придётся торопиться, но и поломать процессы, повысить напряжение и количество коммуникаций, что приведёт к меньшей стабильности. При этом релиз — не конец пути, могут быть ещё и хотфиксы, команда должна быть готова к этому, а не выжата под конец сезона.
Хочется всё ровно наоборот: фича может зарелизиться, но только если мы всё сделали спокойно, контролируем и можем безопасно откатиться.
Решение: не торопимся, фича выйдет в январе.
Подготовка к Новому году
Раз новогодние праздники — это время повышенных нагрузок, то нужно к этому подготовиться. Мы постоянно проводим нагрузочное тестирование для бэкенда, хотя бы потому, что пиковые дни в Додо Пицце случаются равномерно круглый год: 14 и 23 февраля, 8 марта, 1 и 9 мая, 1 июня, 1 сентября. Тем не менее, Новый год — продолжительнее. Сначала он даёт высокую нагрузку в декабре, а затем долгий период без релизов в январе, поэтому нужно уделить особое внимание тем местам, до которых обычно руки не доходят.
Повысить качество сервиса
Подумать о кейсах, которые могут всплыть при нагрузке на пиццерии. Например, заказы на отложенное время очень часто приходятся на обед, а это сверхнагрузки на производственную линию. Вместе с корпоративами и большими заказами комбо-наборов это может создавать лавинный эффект, мы не сможем или произвести, или доставить такое количество.
Узнать у саппорта о самых частых проблемах, разобрать кейсы, специфичные для Нового года. Так мы снизим нагрузку на поддержку и дадим им возможность обработать наплыв обращений.
Снизить нагрузку на процессы. Например, если везём заказ дольше часа, то дарим сертификат на следующую бесплатную пиццу. Недавно эти сертификаты стали электронным и теперь они не могут закончиться, курьер не сможет забыть его выдать — это просто больше не его задача.
Повысить прозрачность
Построить дашборды, которые покажут потенциальные проблемы.
Подчистить ошибки в логах, чтобы не отвлекаться на них в случае ЧП.
Убрать старые тоглы, чтобы удалить код и «выпрямить» его. Возможно, так и проблемы покажутся.
Проверить места отказа
Профилировать приложение по скорости и памяти, добавить трейсинг на важные места.
Поднять crash free.
Проверить безопасность приложения.
Проверить старые версии iOS.
Проверить сценарий недоступности бэкенда при высоком количестве заказов.
Обработать недоступность пиццерий 1 и 2 января, когда заказ сделать нельзя.
Таким образом, все задачи делятся на два блока: либо повышаем качество наших проверок, либо готовимся к потенциальной нагрузке (и даже возможным падениям). Лучше перебдеть.
Подойти к задачам можно двумя способами:
если задач много и они важные, то стоит выделить общий спринт-«субботник», когда все команды берут задачи из бэклога подготовки к Новому году и сфокусировано разгребают его, не отвлекаясь на фичевые задачи;
если задач немного или они некритичные, то можно делать их в общем потоке, лишь сместив баланс фичи/теходолг в пользу второго.
В мобильной разработке мы пошли вторым путём, а бэкенд временами устраивает субботник на пару дней.
Не релизишь? Не пиши код. Код-фриз
По расписанию последний релиз 13 декабря, затем две недели до Нового года мы ничего не релизим, а ведь в январе ещё пара недель праздников. Между релизами проходит месяц, за это время обратную связь от пользователей получить невозможно.
Если две недели все будут писать код и не будут его релизить, то после каникул у нас на продакшен поедет туча изменений, что резко повышает риск что-то сломать.
За время каникул могут происходить инциденты, и хотфиксы, с ними связанные. С большой вероятностью придётся решать мёрж-конфликты не только с релизом, который был написан до Нового года, но и со всеми хотфиксами, которые уже на продакшене.
После возвращения с каникул можно просто утонуть и запутаться в своём и чужом коде, который был написан в предпраздничном настроении. А уж если это придётся делать на инциденте после неудачного большого релиза.
Для планирования сроков важно понимать, какое время поставки кода на продакшен.
Мобильные приложения у нас релизятся каждые пару недель, для них остановка релизов в декабре не будет заметна.
Бэкенд релизится несколько раз в день. Для него простой в пару недель превращается в огромную проблему: изменения копятся, риски увеличиваются, миграции выстраиваются в ряд. Ком изменений может быть настолько огромным, что мы останавливаем разработку на этот срок. Не релизишь — не пишешь код.
Релиз-фриз бэкенда влияет на мобильную разработку: довольно мало фич, которые бы мы можем сделать на фронте без изменений бэкенда, поэтому тоже перестаём разрабатывать 13 декабря:
неделю мы оставляем для критичных фиксов;
неделю не могли зарелизить из-за магазинов;
вопросы про остальные две недели надо направить президенту РФ.
Выходит, это целый месяц «ничего-не-делания». Или не совсем?
Что ещё полезного можно делать в код-фриз
Если не пишем фичи, то это не значит, что все уходим в отпуск (хотя отпуск — тоже вариант). Что можно делать в код-фриз:
заняться инфраструктурой переводов, сборки или релиза;
заняться дизайн системой и доступностью;
учиться тестам, писать тесты, профилировать приложение;
составлять или причёсывать бэклог;
удалять лишние файлы с компа, открытые вкладки браузера прочитать и закрыть, заметки разобрать;
писать запросы к аналитике, строить дашборды;
проверять работу приложений на старых версиях телефонов;
читать статьи, писать статьи, готовить презентации, снимать видео;
проходить курсы, готовиться к ним или проводить их;
придумывать идеи для 1 апреля и пробовать их.
Чем ближе к Новому году, тем больше хочется отдыхать и развлекаться, поэтому в последние дни декабря мы уходим в отрыв и устраиваем хакатон. Конкурс проходит как в офисе, так и удалённо: все участники получают промокод на пиццу от компании, в случае победы подарки отправляются адресатам в разные города. Так в прошлом году мы попробовали написать App Clip. До релиза он не дошёл, но сделали прототип и поняли, как нам распиливать приложение. К App Clip мы ещё вернёмся!
Счастливого Нового года!
Весь четвёртый квартал у нас проходит в особом режиме: реального времени на разработку в два раза меньше, нужно заранее учесть задачи для подготовки к высокой нагрузке, а в середине декабря наступает код-фриз.
Основная цель всего этого планирования — чтобы всем было хорошо и спокойно: задачи делались в размеренном темпе и выходили вовремя, «нежданчиков» и горячки минимум, в декабре отличная прибыль, а в январе все отдыхаем и не выбегаем на работу по пейджеру.
Многое из рассказанного — лишь заплатки на те процессы, которых пока нет на регулярной основе. Тем не менее, подготовка раз в год позволяет справиться с текущими проблемами.
Подписывайтесь на канал Dodo Mobile, я напомню о наступающем Новом годе в следующем сентябре.
Что такое фича. Объясняем простыми словами
Фича — дополнительная функция или особенность продукта.
Изначально фичами называли необычные функции в компьютерных программах и играх, потом так стали говорить и про гаджеты, и про технику («Мой чайник светится, когда я его включаю, а у твоего есть такая фича?»).
В языке бизнеса и маркетинга слово «фича» практически приобрело статус термина. Различают несколько видов фич. Например:
Пример употребления на «Секрете»
«Ещё вьетнамцы очень любят смотреть онлайн корейские сериалы. И такая простая фича, как возможность свернуть окно браузера и продолжить смотреть видео в фоновом режиме, им очень понравилась. Те инструменты, к которым мы уже привыкли, здесь ещё просто никем не созданы. Мы там как будто люди из будущего».
(Соосновательница компании СосСос Кристина Мелентьева — о том, как её компания потеснила Google во Вьетнаме.)
Нюансы
Предприниматели, развивая свой бизнес, постоянно находятся в поиске новых фич. Но не всегда просто понять, какая функция окажется полезной, а какая навредит. Для этого существует feature/product fit — процедура оценки потенциальной пользы от новой фичи. Иногда правильное решение — отказаться от лишних функций: например, раньше во «ВКонтакте» у пользователей был рейтинг, а «Инстаграм» позволял организовывать путешествия и объединяться в группы. Оценив пользу этих функций, от них отказались.
Практика
Вы наверняка не раз слышали фразу «Это не баг, это фича». Она описывает ситуацию, когда ошибку пытаются представить как «это так задумано». На самом деле, многие прикольные фишки и функции и правда появлялись случайно, в результате ошибки, а потом становились популярными у пользователей. Например, такое часто случалось в компьютерных играх:
«Не баг, а фича» — учимся понимать язык программистов
Понять смысл IT-терминов можно, только узнав, как они употребляются
Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.
Есть куча статей, объясняющих смысл терминов, но неподготовленному человеку от них мало пользы. И если вы общаетесь с программистами или собираетесь стать одним из них, то, скорее всего, во всём придётся разбираться самостоятельно. Иначе можете оказаться в ситуации, похожей на ту, что в клипе:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).
Дисклеймер. Все совпадения случайны, а персонажи и ситуации вымышлены. В художественных целях они наделены негативными качествами, поэтому не берите с них пример: это касается как профессиональных качеств, так и отношения к алкоголю, курению и энергетическим напиткам. Также некоторые слова используются и в других сферах.
Новая задача
Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.
Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).
Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).
Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.
Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.
Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.
Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).
На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.
Валидация — проверка данных, которые вводит пользователь.
До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:
— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.
— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?
— Надо проверить в гитхабе историю коммитов.
Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.
Репозиторий — хранилище исходных файлов проекта.
Foo и Bar — имена функций или переменных, по которым невозможно понять, зачем они нужны. Использование таких имён допускают в учебниках и документации, но не в реальных проектах, потому что они замедляют чтение и понимание кода другими программистами.
Говнокод — очень плохой код.
Код ревью — проверка кода.
Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.
Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.
У стола его уже ждал тимлид:
— Ваня, после того как ты добавил функцию загрузки фотографии в личном кабинете, появился баг. Теперь всё ломается, если ввести промокод.
— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.
— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.
— Но у меня уже есть задача на эту неделю, я не успею всё исправить.
— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.
Тимлид ( англ. team leader — лидер команды) в данном случае — программист, который выполняет роль менеджера. Тимлид редко пишет код, вместо этого он следит, чтобы его команда хорошо справлялась с задачами.
Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.
Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.
Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.
Исправление багов
Дебажить было сложно, но Ваня не мог облажаться и в этот раз. За год его уже успели уволить из трёх компаний, после четвёртого увольнения его резюме будет испорчено окончательно.
Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.
Три дня и три ночи Ваня корпел над кодом, но ничего не выходило. В отчаянии он обратился к коллеге, который проводил код ревью для его коммита в прошлый раз.
— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.
— Но ты же написал lgtm в комментарии!
— И теперь мне за это прилетело. Слушай, я уже сто раз пожалел, что помог тебе сюда устроиться. Тимлид просёк, что я сквозь пальцы смотрю на твой код, поэтому сейчас проблемы у нас обоих. В случае чего я найду новую работу, а ты — вряд ли. Так что сейчас у тебя отличный повод подтянуть знания.
— Ладно, разберусь как-нибудь.
Апрув ( англ. approve) — подтвердить что-нибудь.
Пул реквест ( англ. pull request) — запрос на подтверждение коммита.
LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.
Осталось всего два дня, чтобы исправить баг и добавить новую фичу, а у Вани не было почти никаких продвижений. После работы он, как обычно, зашёл в магазин, но вместо энергетиков решил взять пиво, потому что вспомнил о Пике Балмера.
Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.
Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.
Наутро он не сразу понял, что проснулся, и, лёжа лицом на клавиатуре, продолжал слушать разрывающийся будильник. Прошло всего несколько минут, но Ване они показались вечностью.
Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.
— Я разобрался с багом.
— Отлично, но странно, что у тебя ушло так много времени. Давай протестируем твой код и выгрузим на прод.
Прод или продакшн ( англ. production environment — рабочее окружение) — компьютер (чаще всего сервер), на котором запускается готовое к работе приложение.
Тестирование прошло успешно. И хотя Ване стало спокойнее, он не спешил радоваться — за полтора дня нужно было успеть выполнить задачу, на которую требовалась как минимум неделя.
К счастью, недавно он начал изучать JavaScript, поэтому мог просто скопировать код валидации с фронта и переделать его для бэкенда.
JavaScript — язык фронтенд-разработки.
Помучившись день, он всё-таки закончил. Тимлид оценил усилия:
— Ну вот, можешь же, когда захочешь. Тебе повезло, что мы не деплоим на прод по пятницам, поэтому у тебя ещё есть время до середины понедельника, чтобы ещё раз всё проверить и поправить.
Деплой ( англ. to deploy) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.
Воодушевлённый успехом, Ваня ещё раз всё протестировал, поэтому к следующему митингу он был спокоен — больше исправлять старые баги ему не придётся.
По крайней мере на этот спринт.
Заключение
Научила ли чему-нибудь Ваню эта история? Возможно. Но вы наверняка стали на один шаг ближе к пониманию программистов. Или даже к тому, чтобы стать одним из них.