что такое баг в коде

Что такое баги, ворнинги и исключения в программировании

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

Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.

В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Ошибки в программировании

Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:

Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.

Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:

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

После восклицательного знака в треугольнике — количество предупреждений

Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:

Вот результат работы такого кода:

Баги в программах

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

Но они могут привести и к более серьёзным последствиям. Если неправильно спроектировать работу многопоточного приложения, то потоки будут постоянно опережать друг друга. Например, сообщение об ошибке из одного потока может опоздать на миллисекунду, из-за чего второй поток подумает, что никакой ошибки не было, и продолжит работу.

Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.

Исключения в программах

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

Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.

Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.

Одно из самых известных исключений — переполнение стека (англ. stack overflow). В честь него даже назвали сайт, на котором программисты ищут помощь в решении своих проблем.

Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:

Вот аналогичный код на языке C#:

Однако сообщение в этот раз более конкретное:

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

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

Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):

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

Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.

Как избежать всех этих ошибок

К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.

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

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

Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:

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

Заключение

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

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

Источник

Баги и ошибки — как искусство

Введение

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

Что такое “БАГ”

В программировании баг (англ. bug — жук)— жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, сделанных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, “глючной”, “глюкнутой”, “забагованной”, “бажной”, “баг (а) нутой” (англ. unstable, buggy). Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге, также называют отчетом об ошибке или отчетом о проблеме (англ. bug report). Отчет о критической проблеме (англ. crash), вызывающей аварийное завершение программы, называют крэш репортом (англ. crash report). «Баги» локализуются и устраняются в процессе тестирования и отладки программы. Возможны ситуации, при которых ошибки остаются во внутреннем коде или программе они могут остаться не замеченными и обнаруженными уже при тестировании или выпуске программы или игры. Такие ситуации исправляются так называемыми “патчами” (англ. patch), выпускаются они как можно скорее стараясь залатать все дыры и проблемы, когда патч готов разработчик или программист выпускает “патч ноут” (англ. Patch note) список изменений и исправлений. На этом с терминологией всё, приступим к практике.

Как выглядит баг

И как его исправить

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

Место без текстур в Fallout76 – источник

Творческие решения

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

Критические ситуации

За примером далеко ходить не надо, можно вспомнить лица из Assassin’s Creed Unity, проблема была вызвана несовместимостью с некоторыми видеокартами, это ошибка была исправлена в патче первого дня но оставила свой отпечаток на и так большом пласте ненависти ввиду отсутствия оптимизации и багов, вот что об этом говорит главный творческий руководитель Ubisoft Жан Жесдон:

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

Именно поэтому Syndicate концентрировалась на качестве, с чем команда отлично справилась. Жан Жесдон

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

Источник

Типы багов: этимология и энтомология

1. Немного этимологии и энтомологии
Давайте посмотрим попристальней на такое знакомое и (до боли?) родное слово БАГ. Происходит оно от английского слова Bug, означающего «насекомое». Есть еще много сторонних значений, в частности английское выражение «to go bugs» — сойти с ума, что легко кореллируется со вполне русским «тараканы в голове завелись». Также вспоминаются и «жучки на линии» (тоже, кстати, по-английски – bugs). И опять мы пришли к насекомым.

Еще в 1878 году, Томас Альва Эдисон (да-да, тот самый!) в письмах к своему соратнику Пускасу писал: «It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that ‘Bugs’ — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached». Тем же словом, инженеры называли и сбои радарной электроники во время второй Мировой Войны. Конечно, более распространена история о том, что в 1946 году разработка компьютера Марк-2 (Mark-II) были приостановлена из-за сбоя его функционирования, вызванного попаданием мотылька между контактов. Трупик мотылька был извлечен и приклеен к отчету липкой лентой с комментарием «First actual case of bug being found.» («Первый реальный случай нахождения жучка»). Как нетрудно догадаться, примерно оттуда же «растут уши» и слова «дебаггер» (debugger) – буквально «избавитель от жучков».

2. Виды багов.
Простейший (не как инфузория-туфелька, а самый простой для понимания, модно сказать «классический») баг – это несоответствие между ожидаемым результатом (ОР) и фактическим результатом (ФР). Разберем это на примере:

(это, кстати, реальный баг старого Microsoft Excel – он не учитывал приоритета математических операций, по которому умножение имеет высший приоритет по сравнению со сложением)

Все просто. Ждем одно – получаем другое. Баг.
Я не буду перечислять все подвиды бага классического – от опечаток в данных и опечаток в коде до бесконечных циклов, от использования оператора присвоения вместо оператора проверки равенства до использования неинициализированной переменной, от состояния гонки (race condition) в мультипоточных приложения до переполнения буфера, и так далее, и тому подобное – все это достаточно обыденные и ясные явления. Обратимся к малознакомой экзотике.

2.1. Гейзенбаг (Heisenbug)
Баг, названный в честь Гейзенбергского Принципа неопределенности – концепции квантовой физики. Простым (хоть слово «просто» здесь и не очень применимо) примером подобного бага будет являться ошибка, проявляющаяся, когда программа запускается на исполнение в рабочей среде, но исчезающая, когда программу запускают в дебаггере.

2.2. Борбаг (Bohrbug)
Тип бага, названный так в честь атомной модели Бора. В противоположность Гейзенбагу, он проявляется постоянно при одном и том же стечении обстоятельств. Вопрос в том, что весь набор обстоятельств бывет невозможно (или очень трудно) отследить.

2.3. Мандельбаг (Mandelbug)
Назван в честь Бенуа Мандельброта, внесшего огромный вклад в теорию фракталов. Мандельбагами называют ошибки, чьи причины настолько сложны и неясны, что фактически кажутся хаотичными и не поддающимися описаниями. (ключевое слово «кажутся»). Подобное, может быть вызвано, например, медленной реакцией системы – то есть ошибка уже произошла, но об этом вы узнаете только через некоторое время, что сильно затруднит локализацию причин.

2.4. Шрединбаг (Schroedinbug)
Шрединбаг назван в честь известного парадокса с кошкой Шредингера (или эта несчастная животина – кот?). Он заключается в том, что кто-нибудь читает код программы (работающей уже некоторое время) и восклицает «Да этого не может быть! Она просто не может функционировать!», после чего программа прекращает свое функционирование пока данная ошибка не будет исправлена. Будучи, казалось бы, абсолютно фантастической, данная ошибка попадается в реальности – спросите знакомых ветеранов- разработчиков, они подтвердят. Хотя, конечно, последующий анализ, как правило, позволяет отнести ошибку к разделам 2.1, 2.2 или 2.3, это удается не всегда.

2.5. Фазы луны
На самом деле такой ошибки не существует – это популярная отговорка тех, кто не хочет (не имеет желания и/или времени) разбираться в сложных причинах возникновения ошибки. Тем не менее, в истории существует пара примеров, когда ошибки возникали буквально из-за фаз луны. Я не буду приводить здесь эти истории, надеясь, что никому из нас не придется работать со столь сложными устройствами. Тем не менее, в любом случае, хотелось бы предостеречь всех от неосторожных умозаключений и попросить быть более внимательными, настойчивыми и скрупулезными в своей работе.

2.6. Статистический (более известный как количественный) баг
Баг возникающий при произведении программой большого количества каких-либо действий. Примером данной ошибки может служить запуск программы, которая должна равномерно расположить на плоскости некоторое количество точек. Если, например, при большом количестве точек программа не только неправильно располагает их, но и норовит расположить все на одной стороне плоскости (при этом до определенного количества точек работая прекрасно) – вуаля, количественный баг.

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

На этом я закончу краткий обзор багов, буду рад Вашим замечаниям и предложениям.

Источник

Моя объединенная теория багов

Типичное распределение видов багов в программе

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

Сложность обнаружения Бага

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

Сложность исправления Бага

Практический опыт может показать нам, насколько сложно исправлять ошибки. Логический баг починить довольно сложно, поскольку для поиска решения вы должны понимать все пути выполнения кода. После внесения правок, мы так же должны быть уверены, что исправления не сломают уже существующую функциональность. Проблемы связывания попрвить легче, поскольку они проявляют себя с помощью exсeption’а или неверным местонахождением данных. Баги отображения сами наглядно показывают, что пошло не так, и вы сразу знаете как это исправить. Мы изначально проектируем нашу программу, учитывая частые изменения пользовательского интерфейса, и поэтому нам легче вносить подобные правки.

Как тестопригодность меняет распределение видов багов?

Так получается, что написание тестопригодного кода влияет на распределение видов багов в программе. Для тестопригодности код должен:

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

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

Мы любим писать модульные тесты (unit tests)

Модульные тесты сфокусированы на логических багах. Они проверяют ваши i’ы и циклы, но не проверяют связывание напрямую (и конечно, не проверяют отображение)

Модульные тесты сфокусированы на КПТ (класс-под-тестом, CUT, class-under-test). Это важно, поскольку вы должны быть уверены, что эти тесты не встанут на пути будущего рефакторинга. Модульные тесты должны ПОМОГАТЬ рефакторингу, а не МЕШАТЬ ему. (Повторюсь: когда я слышу, как кто-то говорит, что тесты мешают рефакторингу, то полагаю, что этот человек не понимает, что такое модульный тест).

Модульные тесты напрямую не скажут, что все OK со связыванием. Они делают это неявно, путем принуждения вас к написанию тестопригодного кода.

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

Управление Багами

Я люблю думать о тестировании как об управлении багами (с целью от них избавится). Не все виды ошибок одинаковы, поэтому я выбираю тесты, на которых нужно сконцентрироваться. Я понял, что люблю модульные тесты. Но они должны быть хорошо сфокусированы! Если тест проверяет много классов за один проход, то я могу быть рад хорошему покрытию тестами, но на самом деле после этого сложно найти то место, которое зажгло «красный» тест. Это также может затруднить рефакторинг. Я стараюсь облегчить себе жизнь при функциональном тестировании: для меня достаточно одного теста, который доказывает правильность связывания.

Я слышу, как многие заявляют, что они пишут модульные тесты, но при ближайшем рассмотрении это оказывается смесь функциональных (проверка связывания) и модульных (логика) тестов. Это происходит, когда тесты пишутся после того, как написан код, и из-за этого он получается нетестопригодным. Нетестопригодный код ведет к появлению мокеров (от англ. «mock» — заглушка) — это тест, для которого необходимо много заглушек, а эти заглушки, в свою очередь, используют другие заглушки. Используя тесты с мокерами, вы будете мало в чем уверены. Подобные тесты работают на слишком высоком уровне абстракции, нужном для того, чтобы что-то утверждать на уровне методов. Эти тесты глубоко завязаны на реализации (это видно по наличию большого количества связей между заглушками), вследствие чего любой рефакторинг будет очень болезненным.

Источник

«Не баг, а фича» — учимся понимать язык программистов

Понять смысл 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) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.

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

По крайней мере на этот спринт.

Заключение

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

Источник