Фёдор Борщёв

Мастер-класс: как написать первый тест на любом проекте

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

26 октября в 14:00 я проведу мастер-класс, где расскажу, как внедрить практику тестирования кода в любой проект — неважно, начинаете ли вы стартап, или накопили уже 200 000 строк кода.

Теории будет совсем немного, в основном будет практика — мы возьмём готовый большой проект на Django и решим на нём бизнесовую задачу при помощи TDD. Python я выбрал потому, что код на нём легко прочитать, а подходы — перенести на любой другой язык. Так что если вы хотите писать тесты на JS, Ruby или Go — тоже приходите, хватит базовых знаний любого языка программирования.

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

До 9 октября действует скидка за раннюю регистрацию, если передумаете — билеты можно вернуть в три клика.

Программистам: что делать, чтобы вас не заменили роботом

Знаний всегда больше, чем можно выучить. А то, что выучивают айтишники, становится неактуальным в 10 раз быстрее, чем в других областях.

Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.

Права рута появились у каждого программиста, а сисадмины стали с умным видом делать гораздо меньше вещей.

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

Если не хотите, чтобы в ближайшее время люди придумали абстракцию, которая вас заменит, остается два пути: или постоянно учить новое (и откладывать деньги на период, когда вы не сможете этого делать по физиологическим причинам), или учить софтскиллы, которые роботом пока не заменить: управление людьми, ответственность и результативность.

Мне сказали — я копаю

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.

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

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

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

Не учитесь технологиям — учитесь решать задачи

Начинающие программисты часто спрашивают в личке — как правильно выбирать технологии? Что учить, чтобы не отставать от прогресса? Это — плохой вопрос, учить надо вовсе не технологии.

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

Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.

Когда умной компании нужно построить дом, она ищет не людей, которые умеют работать с молотком, а людей, которые умеют строить дома. Чем вы построите этот дом: шуруповёртом, подъёмным краном или нанятой командой монтажников — не так уж и важно. Важно ваше умение решать задачи, при необходимости включая в арсенал неизвестные инструменты.

Так что пофиг, на каком стеке технологий вы работаете — его всегда можно поменять. Важне ваше умение применять этот стек для решения прикладных задач. Так что просто берите что-нибудь популярное (кроме JS) — и фигачьте.

Feature flags

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

Чаще всего набор фиче-флагов формирует фронтенд, и отсылает на бекенд в момент каждого запроса. Так можно легко ставить a\b тесты — просто выбираем две когорты, одной добавляем фичу, а другой — нет, и смотрим на поведение.

Пример реализации — GitHub, который передает фиче-флаги в HTTP-заголовках. Прямо сейчас в API гитхаба таким образом включается-выключается одновременно 30 фич.

Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения в зависимости от среды. К примеру, у нас ЦРМ есть фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг ENABLE_NOTIFICATIONS и включаю его только в переменных окружения на проде. По умолчанию флаг выключен, поэтому где мы ни развернули мой бекенд — он никогда не пошлет сообдщений живым людям, если его явно об этом не попросить.

См. также:

  • Подробное объяснение пользы фиче-флагов от самого Мартина Фаулера
  • Launch Darkly — централизованное управление включенностью фич
  • Unleash — то же самое, но бесплатно и self-hosted