[Перевод] «Никаких деплоев в пятницу» и ещё три негласных правила разработки
Всё старое в один прекрасный день снова становится новым. Наступает время, когда даже опытные программисты наступают на те же грабли. Невозможно перечислить все «неписаные правила» любой дисциплины, отчасти потому, что многие из них — даже не правила. Зачастую это способ перефразировать абстрактные и вечные истины.
Мари Кондо сделала карьеру, применив универсальные принципы эффективности, чистоты и красоты к бытовой задаче ведения домашнего хозяйства. Оказывается, многим людям нужен просто переводчик между вечной мудростью и их повседневной жизнью, чтобы действительно «понять» смысл происходящего вокруг (см. также «Дзен и искусство обслуживания мотоциклов»). Мы искренне надеемся, что вам понравится наша попытка сделать то же самое для программирования.
Даже если у вас система непрерывного развёртывания. Пятница — самый неподходящий день, чтобы запушить мастер, по очевидной причине: остаётся всего полрабочего дня на исправление возможных косяков. Обычно после обновлений наблюдаются всплески в тикетах техподдержки, особенно после выпуска новых функций и, неизбежно, новых ошибок. Люди по пятницам сонные, невнимательные, склонны всё откладывать на потом… знаете, как это бывает.
Никто не застрахован от потусторонних сил, которые всегда выбирают пятницу для багов! Поэтому наблюдайте за лучшими практиками, а если не уверены, обратите внимание на лидеров отрасли. Например, Apple, предположительно, делает релизы по вторникам, оставляя достаточно времени с двух сторон такого критического события как деплой: понедельник, чтобы оттестировать и выловить последние ошибки, а со среды по пятницу — чтобы внести любые срочные изменения. И с доходами Apple вы понимаете, что их модель деплоя обмыта кровью и потом.
Трудно переоценить важность регулярного резервного копирования. Вся наша индустрия построена на абстрактной системе прогрессивного бэкапа. Конечно, я говорю о Git, но этого недостаточно. Ваша БД, криптографические ключи, конфигурационные файлы, образы VM, изображения/видео… даже импортированные пакеты следует надёжно хранить там, где они будут всегда доступны в случае чрезвычайной ситуации. Если у вас нет автоматизированной системы, то пусть хотя бы парочка сотрудников регулярно архивирует рабочую папку и копирует на внешний диск. Да, именно парочка — избыточность не лишняя.
Вероятно, вам никогда не пригодятся 9 из 10 сделанных резервных копий. Но однажды, как я сегодня, вы захотите вернуться в прошлое и выяснить, когда именно мы сделали эту незаметную, но совершенно убийственную ошибку, которую никто до сих пор не замечал?! Тогда вы будете рады, что нашли время на бэкап. Или, ну вы знаете, когда новый сотрудник случайно удалит 100 000 строк кода. Бывает. Мы не держим обиды на людей, а учимся на ошибках. Делайте бэкапы, даже если это тяжело!
Я часто страдаю синдромом «начал слишком рано». Не раз приходилось переписывать большие фрагменты кода, потому что я не задал достаточно вопросов на первых встречах с заказчиком, где тот обрисовал контуры задачи. Наш мозг действительно крошечный, и он ненавидит точность, особенно когда точность сложна и дорога (читай: необходима клиенту). Он находит сходство там, где его и близко нет. Это особенно верно в дизайне программ — в достаточно сложном приложении десять похожих кнопок выполняют десяток совершенно разных задач. Перед началом кодирования следует уловить эти тонкости, если вы хотите получить максимальную отдачу от своего времени и времени клиентов. Не будьте таким, как я или мой мозг. Нарисуйте всё на бумаге, убедитесь, что всё понятно, а при необходимости можете перерисовать систему с нуля (с учётом достаточного время на подготовку — все мы люди).
Никто никогда не достигнет совершенства в этом процессе. Я всё ещё слишком часто полагаюсь на догадки. Но с тех пор, как я осознал проблему, необоснованных предположений стало меньше. Следует размышлять как компьютер: недвусмысленно и бездумно в своей логике. В концепции проектирования системы изучайте пограничные ситуации, будьте «адвокатом тестера» — и вы, вероятно, найдёте дизайн, который сразу исключает целые классы ошибок, допустимые в менее продуманном дизайне.
Постарайтесь мягко остановить или предотвратить непродуктивные дискуссии, прежде чем они выйдут из-под контроля. Наше время в офисе почти так же ценно, как те 3–8 часов, которые мы проводим без сознания каждую ночь — то есть оно очень важно! С точки зрения бизнеса, чем больше народу — тем эффективнее должна быть встреча, потому что почасовая оплата умножается на 20–500 разработчиков в одной комнате / конференц-зале / и т. д. Это сумасшедшие деньги, особенно в солнечной Калифорнии с её зарплатами. Время — деньги! И мы отрабатываем эти деньги, придумывая интеллектуальные трюки вокруг монстров со щупальцами, которые скрываются за каждой кодовой базой и только ждут, чтобы разбить невинные ожидания жестокими багами и сбоями.
Но мы не всегда бродим по забытым кодовым катакомбам с дрожащим факелом и потным лбом. Иногда мы сидим на собраниях или напряжённо что-то обсуждаем вне формальных митингов. Slack славится тем, что повышает сплочённость команды, но какой ценой (кроме ежемесячной платы)? По моему опыту, Slack резко увеличивает «бессмысленное время» вашего мозга — время, потраченное на фильтрацию ещё одного постоянного потока (часто неуместных) звуковых оповещений, когда вы пытаетесь делать то, за что компания вам платит; то есть разрабатывать и ремонтировать полезный код. А люди довольно легко впадают в ненужные споры.
Ничего страшного в том, чтобы попросить закончить дискуссию, если она займёт слишком много времени. В наше время дети любят говорить, что «настоящий видит настоящее»: люди, которые действительно делают реальную работу, помогают клиентам, пользователям и миру, — они будут благодарны вам за то, что вы попросили закончить дискуссию о том, должен быть новый холодильник чёрным или хромированным. «Да бросьте вы монетку, какая разница… у нас более серьёзные проблемы». И многие из людей, которые обратят на вас внимание, будут из руководства.
Спасибо, что присоединились ко мне в этом путешествии. Да увидите вы ту же мудрость, что и те, кто впервые до нас написал эти советы. И, пожалуйста, если на своём опыте вы усвоили какие-то ещё негласные правила, напишите их и сообщите нам!
