что такое баг фиксинг
Bug Bounty: заработай на чужих ошибках
В этой статье я расскажу о Bug Bounty программах, их плюсах и минусах, а также как на этом зарабатывают.
В первую очередь давайте определим что такое Bug Bounty: программа выплата награды за обнаружение проблем в безопасности сервисов и приложений компании. На русский язык уместнее всего это переводится как «Охота за ошибками».
Т.е. это некий свод правил «взаимодействия» с информационными ресурсами компании. Обычно в него входит регламент проведения программы, перечень ресурсов, описание принимаемых уязвимостей, размеры вознаграждения. В классическом исполнении это описание того, что можно «ломать» и сколько багхантер получит за ту или иную уязвимость.
Так выглядит Bug Bounty снаружи. Что это дает компании? В первую очередь непрерывный процесс «проверки на прочность»: специалисты с различным уровнем знаний, инструментарием и часовыми поясами в режиме нон-стоп атакуют ресурсы компании. Со стороны компании задействованы ресурсы на:
Bug Bounty плюсы и минусы
Теперь остановимся на плюсах и минусах Bug Bounty программ.
Очевидными плюсами будет:
Очевидными минусами будет:
Зачастую многие багхантеры, участвующие в программах Bug Bounty ограничиваются своими «коронными» фишками, и не исследуют что-то другое, либо наоборот, ставят под сканеры все подряд в надежде уловить хоть что-то. Это дает разноплановый, но не полный подход к тестированию. Также, огромное количество фолс срабатываний сканеров может завалить команду разработчиков ненужной работой (это и дополнительные проверки и отклики по каждому репорту — которых может быть очень много).
Открытые программы
Большинство компаний представлено на площадках — агрегаторах, таких как HackerOne или BugCrowd.
Многие российские компании открыли как собственные программы, так и профили на HackerOne. Среди них такие компании, как: Яндекс, Майл.ру, QiWi, Вконтакте и многие другие. Да что говорить, если даже у Пентагона есть своя программа Bug Bounty. (Взломать Пентагон, получить деньги и остаться на свободе — похоже на мечту хакера, но уже суровая реальность).
Вот, например, оценка стоимости обнаруженных уязвимостей в программе «Охота за ошибками» — Яндекс:
Наиболее «дорогие ошибки»
Выявление известной уязвимости:
Россиянин обнаружил в программном обеспечении соцсети ошибку, которая с помощью специальной картинки позволяла запускать на ее серверах произвольный код. Для этого необходимо было воспользоваться уязвимостью в сервисе ImageMagick, предназначенном для быстрого масштабирования и конвертации изображений в новостной ленте Facebook, сообщает Лента.ру. Леонов случайно наткнулся на ошибку во время тестирования стороннего сервиса, изучил ее и представил всю необходимую информацию техническим службам Facebook, которые устранили уязвимость в ноябре 2016 года. В итоге соцсеть выплатила хакеру вознаграждение в 40 тысяч долларов. В 2014 году рекордную сумму в 33,5 тысяч долларов получил от Facebook специалист по кибербезопасности Реджинальдо Сильва.
Хочу участвовать, что надо делать?
Для тех, кто решил попробовать свои силы и возможности в поиске ошибок могу посоветовать несколько основных этапов, которые приведут к победе:
Следите за новостями. Обновился скоп программы — бегом проверять новые сервисы. Производитель добавил новый функционал, расширил старый или интегрировал сторонний сервис? — большая возможность, особенно в сложной инфраструктуре допустить ошибку.
Упорство. Скрупулезное исследование, не упускать никаких деталей. Хорошая практика будет периодически сравнивать результаты прошлых проверок с текущем состоянием системы.
Поиск. Ищите и обрящете. Большинство крупных багов находят на «не публичных» поддоменах и директориях. Здесь вам пригодятся инструменты по выявлению поддоменов и хорошие листы словарей для брута директорий и поддоменов.
Исследование. Отложите автоматические сканеры, просеивайте веб-приложение (а большинство Bug Bounty связано именно с вебом) как песок сквозь сито для поиска крупинок золота. Здесь я рекомендую использовать Burp Suite или Owasp Zap — лучше инструментов нет. Почти все крупные победы в баутни — результат работы с этими инструментами (практически на любом публичном репорте можно это увидеть).
Исследуйте. Скачайте приложение для локального исследования, если это возможно. Читайте отчеты других участников — это может дать пищу для ума. Тот же взлом фейсбука — многие российские багхантеры видели этот поддомен, даже пытались с ним что-то делать — но «не докрутили». Хорошим подспорьем для этого будет ресурс: The unofficial HackerOne disclosure Timeline
Багфикс человека: как фиксить баги, которые мешают работать
Почему у людей не получается взять — и выполнить задачу? Откуда берутся заминки, неправильные оценки и прокрастинация? Почему люди не понимают друг друга, хотя вроде бы не дураки и общаются на одном языке?
Как оказалось, причина у всего этого одна — когнитивные искажения. Вот про них и поговорим.
Когнитивные искажения — баги в психике человека, которые мешают объективно воспринимать реальность. Их много и они водятся в каждом — на странице Википедии в списке когнитивных искажений под 130 пунктов, и 129 вы, скорее всего, обнаружите у себя. К ним относится сила первого впечатления, желание оправдываться и даже причина, почему мы не можем дать адекватную оценку по задаче.
Когнитивные искажения — как вредные привычки. Жить можно, но лучше бы с ними покончить. И тут с вредными привычками даже проще: мы хотя бы знаем, что курить или точить пиццу под покровом ночи — грешновато, и надо бы в один прекрасный день это прекратить. А когнитивные искажения если в лицо не знаешь — то даже не представляешь, с чем бороться. Сам мозг против этого (но об этом ниже).
Так как когнитивные искажения мешают работать, понимать друг друга и, по итогу, выполнять задачи, от них нужно избавляться. Это касается менеджеров, разработчиков, дизайнеров, аналитиков, копирайтеров — всех. В идеальном мире каждый сам отлавливает и фиксит свои искажения, но в реальности, как мы знаем, без тестировщиков (взгляда со стороны) такое редко случается. Так что будьте готовы: если вы не фиксите свой баг — однажды окружающие придут на помощь и заставят вас это сделать. А я расскажу, как именно 🙂 Не буду рассматривать все 130 искажений — пройдусь только по тем, которые были пойманы в нашей студии и которые часто встречаются у работников ИТ-сферы.
Генерализация частных случаев
Генерализация частных случаев — когнитивное искажение, из-за которого человек расширяет поставленную задачу. При этом он даже не осознает, что её можно выполнить проще и быстрее. Чаще всего встречается у программистов и редко фиксится самостоятельно. Чтобы вправить это когнитивное искажение, нужна помощь менеджера. Как минимум один раз ему придётся включить режим варан-менеджмента.
Так же пристально, как варан за своим будущим обедом, менеджер должен следить за работой разработчика или дизайнера. В отличие от зверей из дикой природы, они не помирают от этого, но — о чудо! — дело делается, а варан остается голодным 🙂 Кстати, программистам это только поначалу неприятно (ну и неприятна сама идея, что с ними так поступят). Дальше, как ни странно — человек втягивается и выравнивается.
Этот метод гарантированно ставит мозги на место и снижает прокрастинацию — и в итоге оказывается, что вместо недели задачу можно без особого напряга решить за один день. Или час. Или 20 минут. Ну вы поняли.
Это невозможно!
Среди когнитивных искажений можно выделить целую группу тех, которые мешают приступить к выполнению задачи. Они тоже чаще встречаются у программистов и дизайнеров, хотя иногда проскакивают и у менеджеров в ответах на хотелки клиентов. И обычно выражаются категоричным: «Это невозможно!».
У такой реакции несколько причин:
Этот баг уже легче отловить самому. Просто нужно помнить и верить, что не бывает невыполнимых задач. Вспомнили — и думайте, какие ресурсы нужны, чтобы выполнить задание.
Если вы словили это когнитивное искажение у коллеги — задайте ему тот же вопрос, какой задали бы себе: «Скажи, пожалуйста, что тебе потребуется, чтобы сделать эту задачу?». И повторяйте его, пока коллега не поймёт, что ему не верят, да и действительно задача не так уж и невыполнима.
Ну и в будущем, если ситуация повторится, на «Это невозможно!» у вас будет кейс, как человек задачу с таким же диагнозом решил за N минут. Напомните ему этот случай пару раз — и дальше он уже научится сам фиксить этот баг.
Проклятие знания
Проклятие знания — ситуация, когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда, кстати, столько непонятых гениев. Среди менеджеров даже больше, чем среди программистов или дизайнеров. В основном этот багуля встречается у неопытных менеджеров — которым кажется, что сделать ВОТ ТАК было очевидным решением, которое даже проговаривать не обязательно (чего, естественно, и не было сделано и не сформулировано в задаче). А то, что программист/дизайнер/аналитик этого не понял — его косяк. Конечно, такое нужно фиксить.
Проклятие знания устраняется самодрессировкой. Нужно отлавливать своё нелогичное поведение и наступать себе на хвост. Пытаться выстроить конструктивный диалог, даже если очень не хочется. А то всю жизнь можно прожить, думая, что все вокруг глупые, а ты один в пальто стоишь красивый. А на деле окажется, что всё совсем наоборот.
Личное оскорбление
Следующее когнитивное искажение — когда критика результата воспринимается как личное оскорбление тем, чью работу критикуют.
Это искажение часто встречается у личностей творческих. Особенно если они не выспались и в плохом настроении. За человека говорят эмоции, поэтому он редко может себя контролировать, обижается и сыпет возражениями. Чтобы вырулить такую ситуацию в конструктив и никого не обидеть, нужно действовать по следующему алгоритму.
Эффект генерации
Отдаю должное: не все когнитивные искажения — причина проблем и непонимания. Бывают и полезные. Например, «эффект генерации». Благодаря этому искажению человек лучше запоминает информацию, когда воспроизводит её сам, а не воспринимает извне. Поэтому если вы сомневаетесь, что правильно поняли задачу, или боитесь забыть — просто повторите её вслух.
Нечто похожее есть в авиационных регламентах. Когда диспетчер на земле передает какую-то информацию, пилот в самолете должен всю её повторить. В такой ситуации высока цена ошибки, поэтому повторение необходимо, во-первых, чтобы исключить помехи и другие лажи со связью. Во-вторых, чтобы пилот успел выставить нужные параметры, пока слушает, и просто считал их с приборов, когда отвечает. И, в-третьих, чтобы закрепить полученную информацию эффектом генерации — бонусом.
Поэтому не бойтесь и не стесняйтесь повторять постановки — это реальный рабочий приём, проверенный пилотами.
Слепое пятно
Это как раз то, о чем я упоминал в начале статьи — мозг не хочет замечать свои несовершенства. Поэтому существует слепое пятно в отношении когнитивных искажений. Даже если человек знает о них, то вряд ли согласится, что они влияют на его поведение. А последствия спишет на обстоятельства и на глупость окружающих. И, соответственно, не сделает ничего, чтобы пофиксить свои когнитивные искажения.
Поэтому если вы замечаете, что задачи делаются с сучками и задоринками, и хотите это изменить — попробуйте оценить объективно, может, причина тому — когнитивные искажения? Если вам кажется, что конечно нет — лучше на всякий случай спросите коллег. Слепое пятно не действует в отношении чужих багов 🙂
Теперь, когда вы знаете про когнитивные искажения, и даже понимаете, в каких именно местах они выпирают и мешают работать, вы сможете с ними бороться. Конечно, будет трудно поначалу, да ещё и слепое пятно будет мешаться. Но со временем оно уменьшится. И тогда и вам, и вашим коллегам станет проще жить и работать — в процессах станет меньше необъяснимых лаж и больше конструктива, мира, дружбы и жвачки.
То, что описано в этой статье — верхушка айсберга когнитивных искажений и аномалий в работе нашего мозга. Если тема вас зацепила и хочется ещё — рекомендую почитать эти книги:
Особенности тестирования кредитов: как один баг влияет на тысячи долларов выручки
Привет. Меня зовут Ольга Михальчук, я QA engineer (Quality Assurance engineer или тестировщик) в финтех-компании ID Finance. В этом посте я расскажу, чем занимаются QA и как искать и исправлять баги в кредитных калькуляциях, пока они не привели к большим убыткам в вашей компании.
Немного о моей работе: QA или тестировщик
ID Finance — финтех-компания, проекты которой представлены в семи странах. Я работаю на Бразилию, продукт MoneyMan (сервис онлайн-кредитования).
Для начала хотела бы немного определиться с терминами «Quality Assurance engineer» и «тестировщик», хотя это и тема для отдельной статьи. Пока нет единого представления об этих понятиях. В большинстве случаев тестировщиками называют специалистов, которые проверяют правильность работы системы после разработки и до предоставления функциональности конечным пользователям. А под QA подразумевают более глобальную и глубокую работу по обеспечению качества продукта. Сюда входит исследование причин возникших дефектов, их предотвращение, пострелизное обслуживание, постоянное усовершенствование процесса и многое другое.
В действительности моя работа выглядит приблизительно так: мы анализируем и проверяем задачи, которые составили другие отделы и разработали программисты, заносим и разбираем баги, пишем тестовую документацию и отчёты, мониторим состояние продакшена, проводим демо и т. д. Также у нас есть понятие Production QA. Ребята из нашего отдела должны иметь представление и о процессе разработки: мы ежедневно спускаемся на уровень баз данных и логирования системы, заглядываем в код и консоль, используем системы мониторинга нагрузки и состояния системы. Мы должны понимать специфику бизнеса: сюда входит и разбор задач и коммуникация с другими отделами. Должны знать особенности работы других департаментов. Пример: как можно протестировать, что начисления по кредиту проводятся правильно, когда ты в этом не разбираешься? Именно поэтому я в дальнейшем буду называть свою должность QA, т. е. специалист по обеспечению качества, хотя не обижусь, если меня назовут тестировщиком.
Тестирование кредитных калькуляций
У нас в компании кредитными калькуляциями называют все вычисления параметров и показателей кредита. Это график платежей, сумма основного долга и процентов, штраф в случае просрочки, начисление пошлин, налогов и т. д. В общей сложности более 100 показателей в разных таблицах базы данных. Кроме основных услуг существуют дополнительные: продление, реструктуризация, реновация. Еще есть система скидок, бонусов, разных кредитных продуктов, доступных пользователю и куча других особенностей.
Кредитные калькуляции – это одна из самых сложных областей, с которой я сталкивалась в течение работы в компании. На мой взгляд, на одном уровне по сложности находится только кредитная политика (набор правил и алгоритмов, по которым принимается решение о возможности выдать кредит, и какой именно кредит мы можем выдать данному пользователю).
Особенности тестирования кредитных калькуляций
Конкретные кейсы: как баги могут повлиять на тысячи долларов выручки и как мы с ними боролись
Я приступила к работе с калькуляциями, когда они уже были в релизе около двух лет, поэтому я не знала многих прелестей зарождения этого процесса. Тем не менее мне пришлось столкнуться с их стабилизацией и фиксингом багов. Расскажу вам о случаях, которые мне наиболее запомнились:
Эффект бабочки в калькуляциях
Если загуглить определение «эффект бабочки», можно увидеть: «Эффект бабочки — термин, обозначающий свойство некоторых хаотичных систем: незначительное влияние на систему может иметь большие и непредсказуемые последствия, в том числе и совершенно в другом месте». Я думаю, это определение идеально описывает ситуацию в кредитных калькуляциях.
Как пример, однажды мы починили незначительный баг: была небольшая неточность в округлениях некоторых полей. После пересчета всех кредитов (благо на тестовой среде), оказалось, что около тысячи кредитов вышли в просрочку, хотя на самом деле не должны были! Так повлиял фикс того незначительного бага, ведь в кредитных калькуляциях все параметры сильно сплетены и влияют друг на друга, порой в неожиданных местах. Слава богу, это быстро заметили, починили, не допустив его попадания конечным пользователям. Дело в том, что информацию о просрочке мы отправляем в кредитное бюро. Мы могли испортить сотни кредитных историй клиентов и свою репутацию. И, конечно, такой баг вылился бы в тысячи долларов убытков.
Нельзя исправить 100% багов
Как я писала в первом пункте, все параметры в калькуляциях очень влияют друг на друга. Из-за этого во время исправления в одном месте очень часто что-то ломается в другом. Когда мы столкнулись с фиксингом большого количества скопившихся багов, конечно, бизнес-отдел хотел, чтобы были исправлены абсолютно все ошибки. Но получилось, что в попытке починить некоторые маловажные баги, вырастали всё новые и новые ошибки, как снежный ком. Как говорится, идеальное – враг хорошего. Поэтому нашей основной задачей на тот момент стало привести систему в максимально стабильное состояние, с минимальным влиянием багов на бизнес, а не исправить 100% дефектов. Такой подход оказался намного продуктивнее, чем бесконечное исправление всё новых и новых багов, плодящихся друг от друга.
Внимание нетривиальным комбинациям
Большинство багов возникает именно при нетривиальных комбинациях способов выплаты и использования кредита, когда ветвления в коде запутываются друг в друге. Например: пользователь погашает первый взнос заранее, второй оплачивает в 5 этапов, на третьем берёт продление, а потом уходит в просрочку на несколько недель… К сожалению, нередко баги в таких кейсах находятся уже на проде. Вывод: обращаем внимание на комбинации кейсов и помним про шестой пункт прошлого раздела (прод среда – кладезь тест-кейсов).
Не трогаем действующих клиентов!
Нельзя допустить, чтобы любые изменения суммы, срока или условий по кредиту затронули действующих клиентов, которые взяли его на определенных условиях. Если такой случай произойдет, это принесёт кучу неприятностей саппорт-отделу и всей компании.
Сравнение кредитных портфелей
Очень эффективный метод проверить, правильно ли работают кредитные калькуляции, если в них были внесены какие-либо изменения, — сравнить кредитные портфели до изменений и после. Это значит, что у нас есть условно правильная база кредитов, с калькуляциями, которые удовлетворяют ожиданиям бизнеса. И мы к этой базе применяем новые кредитные калькуляции, и потом с помощью специальных тулов и data-анализа сравниваем какие-то общие показатели этой кучи кредитов.Например, количество просроченных кредитов до и после изменений или сумму процентов по всем кредитам. Этот способ очень помогает как в тестировании, так и в поиске проблем.
Выводы
Кредитные калькуляции – хоть серьезная и сложная тема, но очень интересная и полная головоломок. При работе с ней надо быть немного и data-аналитиком, и финансистом, и математиком. Но даже такого опасного зверя можно приручить, если найти к нему подход.
А помогут в этом простые пункты:
«Не баг, а фича» — учимся понимать язык программистов
Понять смысл 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) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.
Воодушевлённый успехом, Ваня ещё раз всё протестировал, поэтому к следующему митингу он был спокоен — больше исправлять старые баги ему не придётся.
По крайней мере на этот спринт.
Заключение
Научила ли чему-нибудь Ваню эта история? Возможно. Но вы наверняка стали на один шаг ближе к пониманию программистов. Или даже к тому, чтобы стать одним из них.