Узнайте, что такое настоящий ownership в IT: не просто написать код, а решить проблему от начала до конца. Практические шаги для junior и middle разработчиков.
Есть известная фраза: «30% работы — это код». А остальные 70%? Когда я был джуниором, я брал задачу, писал код, отправлял пул-реквест, его мержили, и я шёл спать. Через три дня проблема возвращалась, и мне снова приходилось её решать. Так продолжалось годами. Я понял, что всё это время я не решал проблемы, а просто писал код. Ownership — это не про написание кода и отправку PR. Это про то, чтобы быть владельцем решения проблемы от начала до конца: от «у нас проблема» до «о ней больше не нужно думать». Это меняет всё. Когда вы берёте задачу, вы берёте на себя ответственность за то, чтобы проблема исчезла навсегда. Освоив это, вы станете настоящим сеньором, а не просто разработчиком с большим стажем.
Прежде чем писать код, убедитесь, что вы понимаете, что именно решаете. Самая распространённая ошибка — начинать с решения. Если вы думаете: «Проблема в том, что нам нужно мигрировать с X на Y», — стоп. Это не проблема, это решение. Настоящая проблема звучит так: «Производительность упала», «Система нестабильна», «Падает на клиенте X». «Мигрировать с MySQL на PostgreSQL» — решение. «Поиск участников сообщества занимает 8 секунд» — проблема. Чувствуете разницу? Запишите настоящую проблему. Затем спросите себя: есть ли другие возможные решения? Индекс? Кеш? Переписать тот кривой запрос? У каждого пути есть свои компромиссы. Выберите лучший. Если пропустить этот этап, вы рискуете потратить две недели на идеальное решение не той проблемы.
# Пример: проблема — поиск участников занимает 8 секунд
# Плохое решение: мигрировать на PostgreSQL
# Хорошее решение: добавить индекс на поле поиска
CREATE INDEX idx_members_name ON members(name);
Большинство проблем в продакшне рождаются из вопросов, которые никто не задал до начала работы. Задайте их сейчас.
Какие они? Какие важны, а какие можно игнорировать осознанно (и задокументировать это)? Участник без аватара, имя с эмодзи, пустой список, часовой пояс, отличный от серверного. Выбор того, что игнорировать, — осознанное решение; игнорировать случайно — это баг, ждущий момента, чтобы взорваться.
Сбой сети гарантирован. Как с ним работать? Повторные попытки? С какой частотой? Как долго? Вебхук упал: повтор с экспоненциальной задержкой? Три попытки? А потом сбросить или отправить в очередь на повторную обработку?
Сколько данных задействовано? Нужно ли что-то мигрировать или чистить? Как получить реальные данные для тестирования? Какие инварианты существуют в данных? И главное: какие предположения о формате данных вы сделали, но ещё не подтвердили? «У каждого участника есть email» — вы проверили это в базе или просто предположили?
Как вы узнаете, что всё работает правильно? Автоматических тестов достаточно? Нужно ли ручное тестирование? Разница видна на скриншоте или видео? Баг в тёмной теме не выявит юнит-тест. Его покажет скриншот.
Как вы сообщите о изменении? Можете ли вы представить анонс? Как это вписывается в общий план? Если вы не можете написать анонс в двух предложениях, объём работ, вероятно, ещё не ясен.
# Пример: граничные случаи для поиска участников
# 1. Участник без аватара — показываем заглушку
# 2. Поиск без результатов — показываем сообщение "Ничего не найдено"
# 3. 50 000 участников одновременно — проверяем производительность
Этот этап самый короткий в описании, но самый долгий в жизни. Правило простое: делайте работу точно, аккуратно, с чувством срочности и спокойствием. Не делайте ничего наполовину. Срочность — это не спешка, это не оставлять проблему ждать, но не жертвовать качеством. Перед мержем задайте себе любимый вопрос: «Я горжусь этим? Я бы показал это Джону Кармаку и сказал: вот что я построил с такими-то ограничениями и компромиссами?» Если ответ «нет», работа ещё не закончена.
# Пример: добавляем индекс и переписываем запрос
# После изменений время поиска упало с 8 секунд до 120 мс
# Я горжусь этим результатом
Закончить писать код — не значит закончить. Закончить — значит проблема решена, работает и в продакшне. Запомните это.
Тестируйте вручную. Да, у вас есть автоматические тесты. Но тесты проходят, а фича ломается. В 99% случаев вы можете подтвердить, что всё работает: запустите сами, попросите коллегу пройти сценарии, проверьте данные до и после, сделайте скриншоты, запишите демо. Вы уверены, что решили проблему? Пройдите весь поток как пользователь: создайте аккаунт, выполните действие, проверьте результат в базе.
Убедитесь, что изменения попали в продакшн и работают там. Деплой прошёл? Что-то сломалось? Нужно включить фича-флаг? Он работает? Вы можете подтвердить, что фича действительно в продакшне? «Замёржил» не равно «зарелизил». Откройте продакшн и используйте фичу сами.
# После деплоя я сам открываю поиск и ввожу "Иван"
# Время ответа — мгновенно, всё работает на реальных данных
Код, о котором никто не знает, порождает баги, которые никто не может объяснить. Коммуникация — часть работы, а не дополнительная опция.
Нужно ли знать коллегам? Это новая фича, которую всем стоит протестировать? Новая конвенция в коде? Что-то коварное, о чём все должны знать? Сообщите. Не недооценивайте периферийное зрение команды: знание того, что коллега вчера изменил поведение функции Z, может сэкономить три часа отладки коллеге Y завтра. Изменили кеш сессий? Одно сообщение в канале команды сегодня стоит трёх часов отладки завтра. Это бесплатно, сделайте это.
Нужно ли знать клиентам? Кто сообщил о баге? Кто ждал этого? Сообщите этим людям. Ответьте в треде того, кто открыл issue: «Вышло в сегодняшней версии, можете протестировать».
Нужно ли знать миру? Анонсируйте релиз. Ченжлог, пост в канале анонсов, твит — формат, соответствующий масштабу изменения.
# Пример сообщения в канал команды
# "Поиск участников ускорился с 8с до мгновенного. Кто жаловался — можете тестировать."
Ownership не заканчивается на деплое. Он заканчивается, когда никто больше не должен думать об этом, включая вас.
Есть ли дальнейшие действия? Нужно ли проверить логи через неделю? Запланируйте напоминание: «Проверить частоту ошибок нового эндпоинта в пятницу». Цикл закрывается только тогда, когда вы уверены, что проблема решена и остаётся решённой.
# В пятницу проверяю логи: время поиска стабильно низкое,
# база растёт, но производительность не падает. Цикл закрыт.
Да, это много работы. И на самом деле ещё больше — мы наверняка что-то упустили. Но именно так создаются продукты в маленькой команде. У нас нет проджект-менеджера, нет отдела QA. Мы маленькие, но мы хороши, и мы справляемся со всем этим. И помните: всегда можно попросить помощи, задать вопрос, переделать и перепроверить трижды. Нельзя молча предполагать, что кто-то другой сделает то, о чём вы не подумали. Действуйте прямо сейчас: возьмите свою текущую задачу и пройдите по всем этапам — поймите проблему, спроектируйте, выполните, проверьте, сообщите и сопроводите. Станьте настоящим владельцем решения.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →