Фёдор Борщёв

Нерешаемая задача

В общении с плохими программистами (а ещё строителями, водителями и сантехниками) часто проскакивает тон «нерешаемая задача»:

— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Не получится, мы в этот момент ещё не авторизованы на бекенде :(

— Давай передавать данные о телефонных заказах в Гугль-аналитику? Это невозможно — мы для таких заказов не знаем ID аналитики :(

Это — плохие ответы. Для хороших ответов есть простое правило: в любом письме предлагай решение. Даже если оно будет безумным и нерациональным — не бойся: предложи и напиши об этом.

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

— Давай передавать данные о телефонных заказах в Гугль-аналитику? Давай, только можем либо забить на идентификаторы пользователей, либо интегрироваться с внешним коллтрекингом.

Будьте решателями проблем, а не создавателями.

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

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

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

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

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

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

​stale: бот для гитхаба, который борется с незавершёнкой

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

Вот к примеру сделал я ПР, который немного улучшает кодовую базу. Хотел показать коллегам-разработчикам, и забыл — так пулл-реквест и остался висеть. Бизнес-стейкхолдера у задачи нет, поэтому никто, кроме меня, про неё не напомнит. Или пришёл бизнес с задачей, мы её начали делать, задали пару вопросов — а нам никто не отвечает.

Бот приходит в такие задачи и напоминает, что ничего не происходит. Если работа по задаче не активизируется — закрывает задачу.

Жёсткий автомат формирует в голове тупое правило: забиваешь на свою работу — значит её выкидывают. Такое правило здорово помогает всем отвечать друг-другу вовремя.

Наш бот не совсем политкорректный — ведь незавершённая работа это так плохо:

90% фич вылетает в трубу

Наверное, где-то в мире есть ребята, у которых гипотезы не выстреливают с вероятностью 80% или даже 75%. Но у нас с вами это не так. Фича, которую вы пилите прямо сейчас, улетит у трубу с вероятностью 90%. Пользователи не заметят новую кнопку, робот не сработает, потому что годится только для 0,1% заказов, а письмо, которое вы верстали неделю, никто не откроет.

Повторите про себя пару раз, и как только вы осознаете — вам сразу станет легче жить. Вы перестанете подходить к новым фичам с завышенными ожиданиями (вот сделаем и заживём!). Вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?

Вместо пиления фич вы начнёте проверять гипотезы. Ваш код тоже станет другим — вы начнёте тратить время не на фичи, а на скорость производства новых фич.

Помните мой совет со входом через Инстаграм? Зная о том, что этот вход не будет никому нужен с вероятностью 90%, вы сделаете интеграцию не с инстаграмом, а с auth0, чтобы в будущем сразу проверить 10 других способов входа, 1 из которых окажется рабочим.

Просто всегда помните, что ваша гениальная идея с вероятностью 90% — говно.

P.S. Сначала эта заметка вышла на моём телеграм-канале. Подписывайтесь.

Удалённая работа и контроль результатов

Иногда в командах, особенно офисных, встречаются руководители, которые вместо выстраивания чёткого конвейера, начинают мониторить странные промежуточные метрики, вроде времени прихода на работу или, ещё хуже,  времени, проведенного с открытой IDE.

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

За процесс, наоборот, спрашивать легко: опоздал программист на работу на 5 минут — значит виноват. Тупанул во вконтосик в рабочее время — значит плохо работает.

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