Skip to main content

Не делайте это в производстве

  • Эта публикация - перевод статьи. Ее автор - Stephen Mann. Оригинал доступен по ссылке ниже:

Примерно в марте 2017 года мне позвонили с просьбой пересмотреть код продукта, который должен быть запущен. У этой компании были проблемы с утечками памяти, самопроизвольными сбоями, медленной загрузкой, скачками ЦП, и ее пришлось выпустить через пару недель. Возможно, вы слышали эту историю раньше, но не от меня и не от этой компании. Это происходит удивительно часто.

Мы собрались вместе на выходных и начали вместе просматривать код. Потребовалось около полдня, чтобы найти источник известных проблем, и еще полдня, чтобы написать документ для своей команды инженеров, чтобы исправить их. Запуск прошел успешно, но это заставило меня задуматься, как продукт попал в это место.

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

В этом случае, однако, был отвратительный поворот: всем этим разработчикам не хватало опыта.

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

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

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

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

Что делать новому разработчику?

Естественная тенденция, кажется, спросить у Интернета. Оказывается, это невероятно эффективный подход. 

Это также невероятно опасно.

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

Однажды я натолкнулся на раздел кода, который вызвал у меня чувство пауков. Я мог поклясться, что видел это раньше. Конечно, после вставки строки в поисковик, я нашел точную часть кода в блоге. Естественно, я прочитал все это, вплоть до строки, которая гласила: « Не делай этого в производстве. «

Тем не менее, вот оно, надевая мне шляпу с передовой производственной базы кода.

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

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

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

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

Прежде чем идти дальше, я хочу упомянуть, что каждый человек, вовлеченный в этот беспорядок, имел добрые намерения. Разработчики, написавшие код, хотели создать хороший продукт и улучшить себя. Менеджеры, которые наняли их, хотели то же самое. Авторы блога хотели поделиться полезными решениями. Каждый делал все возможное, чтобы помогать друг другу, и это важно помнить.

Это не было проблемой с людьми.

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

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

Эта проблема побудила меня начать вести блог. Я был благословлен тем, что почти два десятилетия учился у невероятно талантливых наставников, писателей и коллег. Без совета от этих людей я все равно буду писать GOTOзаявления на QBasic (дрожь). Пришло время взять мяч и бежать с ним.

Я подведу итог с этим:

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

Спасибо за прочтение! Пожалуйста, оставьте комментарий или запрос на тему сообщения, или какие-либо идеи для улучшения.