Хабрахабр

[Перевод] «Никаких деплоев в пятницу» и ещё три негласных правила разработки

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

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

Даже если у вас система непрерывного развёртывания. Пятница — самый неподходящий день, чтобы запушить мастер, по очевидной причине: остаётся всего полрабочего дня на исправление возможных косяков. Обычно после обновлений наблюдаются всплески в тикетах техподдержки, особенно после выпуска новых функций и, неизбежно, новых ошибок. Люди по пятницам сонные, невнимательные, склонны всё откладывать на потом… знаете, как это бывает.

Поэтому наблюдайте за лучшими практиками, а если не уверены, обратите внимание на лидеров отрасли. Никто не застрахован от потусторонних сил, которые всегда выбирают пятницу для багов! И с доходами Apple вы понимаете, что их модель деплоя обмыта кровью и потом. Например, Apple, предположительно, делает релизы по вторникам, оставляя достаточно времени с двух сторон такого критического события как деплой: понедельник, чтобы оттестировать и выловить последние ошибки, а со среды по пятницу — чтобы внести любые срочные изменения.

Трудно переоценить важность регулярного резервного копирования. Вся наша индустрия построена на абстрактной системе прогрессивного бэкапа. Конечно, я говорю о Git, но этого недостаточно. Ваша БД, криптографические ключи, конфигурационные файлы, образы VM, изображения/видео… даже импортированные пакеты следует надёжно хранить там, где они будут всегда доступны в случае чрезвычайной ситуации. Если у вас нет автоматизированной системы, то пусть хотя бы парочка сотрудников регулярно архивирует рабочую папку и копирует на внешний диск. Да, именно парочка — избыточность не лишняя.

Но однажды, как я сегодня, вы захотите вернуться в прошлое и выяснить, когда именно мы сделали эту незаметную, но совершенно убийственную ошибку, которую никто до сих пор не замечал?! Вероятно, вам никогда не пригодятся 9 из 10 сделанных резервных копий. Или, ну вы знаете, когда новый сотрудник случайно удалит 100 000 строк кода. Тогда вы будете рады, что нашли время на бэкап. Мы не держим обиды на людей, а учимся на ошибках. Бывает. Делайте бэкапы, даже если это тяжело!

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

Я всё ещё слишком часто полагаюсь на догадки. Никто никогда не достигнет совершенства в этом процессе. Следует размышлять как компьютер: недвусмысленно и бездумно в своей логике. Но с тех пор, как я осознал проблему, необоснованных предположений стало меньше. В концепции проектирования системы изучайте пограничные ситуации, будьте «адвокатом тестера» — и вы, вероятно, найдёте дизайн, который сразу исключает целые классы ошибок, допустимые в менее продуманном дизайне.

Постарайтесь мягко остановить или предотвратить непродуктивные дискуссии, прежде чем они выйдут из-под контроля. Наше время в офисе почти так же ценно, как те 3-8 часов, которые мы проводим без сознания каждую ночь — то есть оно очень важно! С точки зрения бизнеса, чем больше народу — тем эффективнее должна быть встреча, потому что почасовая оплата умножается на 20-500 разработчиков в одной комнате / конференц-зале / и т. д. Это сумасшедшие деньги, особенно в солнечной Калифорнии с её зарплатами. Время — деньги! И мы отрабатываем эти деньги, придумывая интеллектуальные трюки вокруг монстров со щупальцами, которые скрываются за каждой кодовой базой и только ждут, чтобы разбить невинные ожидания жестокими багами и сбоями.

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

В наше время дети любят говорить, что «настоящий видит настоящее»: люди, которые действительно делают реальную работу, помогают клиентам, пользователям и миру, — они будут благодарны вам за то, что вы попросили закончить дискуссию о том, должен быть новый холодильник чёрным или хромированным. Ничего страшного в том, чтобы попросить закончить дискуссию, если она займёт слишком много времени. И многие из людей, которые обратят на вас внимание, будут из руководства. «Да бросьте вы монетку, какая разница… у нас более серьёзные проблемы».

Да увидите вы ту же мудрость, что и те, кто впервые до нас написал эти советы. Спасибо, что присоединились ко мне в этом путешествии. И, пожалуйста, если на своём опыте вы усвоили какие-то ещё негласные правила, напишите их и сообщите нам!

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»