Допустим, у вас в квартире идёт ремонт. Вы хотите себе лучший ремонт из возможных, поэтому вы испытываете свою ремонтную бригаду по-максимуму. К вам в квартиру регулярно приезжают независимые аудиторы, которые говорят, правильно ли у вас ведётся ремонт. Вы приглашаете экспертов по нагрузке, которые проверяют ваш ламинат на прочность при максимальном весе, а трубы проверяют на протечки при максимальном давлении. Чтобы не вызывать аудиторов по мелочам, по вашей квартире ездит множество роботов-тестеров, которые проверяют ровность стен и прямость углов, а перед приёмкой бригада устанавливает у вас дома набор датчиков, который будет следить за состоянием ремонта в процессе эксплуатации.
Это краткое описание того, что делают программисты, чтобы их программы были надёжными. Несмотря на то, что главная цель программистов — написать фичу, мы регулярно проверяем код и на отсутствие серьёзных багов. Для этого у нас есть масса техник и приёмов, которыми мы пользуемся.
Самое простое, что у нас есть среди таких техник — это процесс код ревью (code review). Обычно какой-то модуль программы пишет один программист, и по окончании работы над ним его показывает другим программистам. Тогда они набрасываются на этот код с целью выявить там возможные ошибки. Это и есть код ревью. Ошибки могут появляться по разным причинам: по незнанию особенностей работы системы, по невнимательности программиста или просто по недопониманию требований заказчика. Наличие ошибок — это нормальное явление, и даже у самых опытных программистов так или иначе может замылиться глаз, особенно при работе со сложными системами.
У программистов также есть какое-то представление о гигиене, и, в частности, о гигиене кода. Хороший код должен быть чистым и красивым, легко читаться, все скобки должны быть правильно расставлены, а переменные — корректно именованы. Для поддержки кода в чистоте существуют специальные программы, линтеры, которые предупреждают разработчиков о возможных проблемах в коде и даже сами исправляют самые примитивные ошибки.
Программы невероятно огромны. В одной программе могут быть сотни тысяч строк кода! Из-за этого программисты для тестирования своих программ часто пишут другие программы, так называемые «автотесты». Типа, я написал код программы, который добавляет номер телефона в телефонную книжку. Я к этому коду сразу же написал код теста, который проверяет, что нельзя добавить один и тот же номер телефона дважды. Такие тесты запускают каждый раз при сдаче нового модуля — таким образом, при каждой приёмке мы знаем, что новый код не внёс ошибку в старом.
Но никакие автоматические тесты не могут заменить работу человека, поэтому в компаниях по разработке программ есть целые отделы, которые занимаются ручным тестированием. Они смотрят новые фичи, которые добавили программисты, и проверяют то, что сами программисты могли недосмотреть. Люди в этом отделе носят пафосное название Quality Assurance Engineer, или же «инженер по качеству». Впрочем, пафос названия весьма оправдан — хорошие QA инженеры не только проверяют код на отсутствие ошибок, но и проверяют качество программы в целом.
Например, программисту могла прийти задача «показывать американцам мили вместо километров». Этот ленивый программист добавил рычажок «переключить с метрической системы на имперскую», который пользователь должен сам дёргать. QA вместо этого мог бы предложить автоматически определять, что пользователь находится в США, и сразу показывать мили. Формально задача была выполнена без ошибок, но переключать автоматически может оказаться удобнее — и качественнее.
И вот программа написана, протестирована и сдана. Думаете, это конец? Как бы не так! Работа над программами продолжается и после их сдачи — и это, кстати, именно та причина, по которой ваши приложения в телефоне постоянно просят обновиться.
Чтобы отслеживать и обнаруживать какие-то проблемы, не предусмотренные на этапе разработки, программисты добавляют в код метрики. Попытка пополнения баланса кошелька окончилась неудачей? Пользователь получил неудаляемый предмет в инвентаре? Игровой сервер нагрелся и тормозит? Большинство проблем такого рода отслеживаются именно при помощи метрик — они позволяют увидеть проблемы и приступить к их решению ещё до того, как жалобы начали прилетать массово. Иногда у нас наступает практически детективная работа: по небольшим обрывкам данных мы пытаемся восстановить картину произошедшего и исправляем ошибку.
Вряд ли большинство пользователей задумываются о том, какая серьёзная работа ведётся над программами для того, чтобы они были максимально надёжными. Не все компании соблюдают все эти практики, и даже у самых хороших компаний в программах неизбежно можно найти баги. Но если вы наткнулись на какую-то ошибку и думаете, какие же программисты беспечные, то попытайтесь себе представить, сколько ошибок было бы без всей этой работы, произведённой за кулисами.
#dev@modifier