[Перевод] Не делайте этого в продакшне
Примерно в марте 2017 года меня попросили сделать код-ревью продукта перед запуском. У той компании были проблемы с утечками памяти, спонтанными сбоями, медленной загрузкой, скачками потребления CPU, а релиз был запланирован через несколько недель. Возможно, вы уже слышали эту историю — не от меня и не об этой компании. Она на удивление типичная.
Мы собрались на выходных и начали вместе просматривать код. Примерно через полдня обнаружился источник известных проблем, а ещё полдня заняло написать документ на исправление для разработчиков. Запуск удался, но история заставила меня задуматься: как продукт дошёл до такого состояния.
Когда я общался с разработчиками, они казались умными людьми. Единственной очевидной проблемой было отсутствие опыта. Я сталкивался с этим раньше. Это распространённое и вполне нормальное явление. Но в этом случае наблюдался гнусный изъян: опыта не хватало всем разработчикам.
Отдел разработки создали недавно, а команду нанимали в отсутствие технического директора. Даже технарю сложно проверить другого программиста — я даже не могу представить себе проверку без технических знаний. Они наняли первого разработчика, он проверил второго разработчика — и так далее, пока не сформировалась команда.
Если вам повезло и у первого разработчика значительный опыт и желание обучать, то вы в дамках. Но если не повезло —, а шансы на это очень высоки — то вы получите стремительную команду, которая создаёт очень хрупкое программное обеспечение.
«Действуйте быстро и ломайте вещи», — говорят они. Но это довольно плохая идея, если бизнес опирается на небольшое количество крупных клиентов. Сломанные продукты их обычно отпугивают, что в свою очередь бьёт по вашему бизнесу. Можно по-разному описывать эффективную стратегию, но фраза «медленно и неуклонно двигаться к цели» явно не впечатляет.
На самом деле существует баланс между быстрым и медленным движением. Трудно нащупать этот баланс, потому что у каждого продукта свой баланс. Предполагаю, что интуиция основывается на опыте, и это ужасный ответ для новичка.
Что же делать новому разработчику?
Кажется естественным поискать ответ в интернете. Оказывается, это невероятно эффективно.
Но это также невероятно опасно.
Я сотрудничал с той компанией и после запуска продукта. Просмотрел значительный объём кода, помог в обучении разработчиков и создал для них новые проекты. Всё прошло гладко.
Однажды моё внимание привлёк один фрагмент кода. Я мог поклясться, что видел его раньше. Конечно, загуглив строку, я нашёл точную копию кода в одной блогозаписи. Естественно, я прочитал всю статью — вплоть до абзаца, в котором говорилось: «Не делайте этого в продакшне».
Но вот эти строчки смотрят на меня прямо из кодовой базы в продакшне.
Не потребовалось много времени, чтобы найти много фрагментов кода из подобных статей. Почти везде был или написан отказ от ответственности, или его явно не хватало. Все они решали один маленький кусочек проблемы, но допускали много вольностей, чтобы сделать код проще для чтения. Это можно понять. Большинство читателей ценят краткость при изучении концепции.
Код из этих блогозаписей распространился по кодовой базе как инфекция, сея проблемы здесь и там без каких-либо причин или закономерностей. И не было никакого очевидного лечения, кроме как читать весь код подряд и вручную исправлять проблемы одна за другой. Без модульных тестов и автоматического развёртывания это заняло почти год. Я почти уверен, что стоимость исправления кода превысила стоимость его написания.
Но какой выбор был у этих разработчиков? Им нужно было что-то выпустить, а они никогда раньше не выпускали приложение в продакшн. Поэтому они сделали то, что попытался бы сделать любой здравомыслящий человек — и учились по ходу дела.
Системы в продакшне выходят из строя невероятным количеством способов. Не имея опыта или теоретического знания об этих сбоях, трудно интуитивно понять, как предотвратить или решить такие проблемы. Трудно требовать от новой команды добиться безупречного результата, особенно без какого-то руководства.
Прежде чем продолжить, хочу отметить, что у каждого человека, кто приложил руку к этому хаосу, были хорошие намерения. Разработчики хотели создать хороший продукт и развиваться. Менеджеры хотели того же. Авторы блогов хотели поделиться полезными решениями. Все старались помочь друг другу, и важно помнить это.
Проблема не в людях.
Я сильно сочувствую разработчикам, которые находятся в таком положении. У них больше информации, чем им когда-либо понадобится, но она полностью дезорганизована. Это похоже на попытку собрать паззл из десяти частей, только нужно найти их в куче из 10 000 000 штук, где все кусочки квадратные, а конечный результат неизвестен. Удачи.
Если вы прочитали досюда, надеясь на ответ, то я сожалею: у меня нет простого ответа. Эту проблему трудно решить. Решение слишком велико для одной статьи, оно меняется каждый день и отличается нюансами для каждого проекта.
Эта проблема побудила меня завести блог. Мне посчастливилось почти двадцать лет учиться у невероятно талантливых наставников, писателей и коллег. Без совета этих людей я бы все еще писал директивы GOTO в QBasic (бр-р-р). Пришло время взять мяч и пойти в наступление.
Подведём итог.
Этот блог посвящён всем аспектам разработки готовых приложений: от автоматизации инфраструктуры до тестирования, проектирования, отладки, документации, процесса разработки и безопасности. Каждая статья независима и подходит для использования в реальном мире — подходит для использования в продакшне.
