Программист на седьмой неделе марафона #100DaysOfCode: почему откат к азам порой важнее нового проекта

Разработчик Abdulmajeed Onatade на седьмой неделе челленджа #100DaysOfCode вместо деплоя нового проекта ушёл в теорию — и не пожалел. Его опыт — хороший повод поговорить о том, зачем профессионалу возвращаться к фундаменту.

Семь недель кодинг-марафона — и ни одного нового проекта на выходе. Зато понимание того, как устроен фреймворк, на котором ты работаешь каждый день. Иногда шаг назад — самый продуктивный шаг вперёд.

Контекст: что такое #100DaysOfCode

Для тех, кто не в теме: #100DaysOfCode — это популярный челлендж в developer-сообществе. Участник обязуется каждый день в течение ста дней писать код и публично отчитываться о прогрессе. Формат простой, но работает как антидот от прокрастинации: ежедневная публичная отчётность создаёт мягкое, но ощутимое давление.

Абдулмаджид Онатаде (Abdulmajeed Onatade) — Java-разработчик, ищущий работу на позицию backend-инженера. К седьмой неделе (дни 38–43) он накопил усталость от интенсивной фазы: за две предыдущие недели успел собрать проект VeriFund, задеплоить несколько штук, поучаствовать в хакатоне и съездить на APIConf 2026. Темп был бешеный, и на седьмой неделе он принял решение, которое в мире стартап-хайпа считается чуть ли не крамольным: перестать строить и начать разбираться.

Что именно изучали

Вместо нового pet-проекта Онатаде ушёл в теорию Spring Framework — основного инструмента в Java-экосистеме для серверной разработки. Вот что попало в его план на неделю:

• Spring AOP (Aspect-Oriented Programming) — механизм для внедрения сквозной логики (логирование, проверка прав, транзакции) без модификации бизнес-кода.
• Dependency Injection — паттерн, при котором объект не создаёт свои зависимости сам, а получает их «извне». Это ключевой принцип, на котором держится весь Spring.
• IoC-контейнер — ядро фреймворка, которое управляет жизненным циклом бинов (объектов) и их связями.
• Spring Security — модуль для аутентификации и авторизации. Включает хеширование паролей через BCrypt, работу с OAuth2, разграничение понятий authentication и authorization.
• Логирование — переход от println-отладки к нормальному логированию через LoggerFactory.
• Паттерны GoF и принципы SOLID — классика объектно-ориентированного проектирования.

На отдельных днях он углублялся в конкретные вещи: сравнение конструкторной и сеттерной инъекции зависимостей, аннотации @Component, @Service, @Repository, @Controller, @Autowired и @Qualifier, конфигурацию приложения через Java-код, аннотации и XML.

Почему это важно — даже если не «шипится»

Здесь стоит остановиться. В культуре разработчиков, особенно в твиттер- и девто-сообществе, есть устойчивый культ shipping: «Ship it!», «Move fast and break things», «Done is better than perfect». И челлендж #100DaysOfCode часто подпитывает эту логику — каждый день должен быть что-то задеплоено, закоммичено, опубликовано.

Но Онатаде делает важное наблюдение: понимание того, как Spring создаёт объекты, как контейнер управляет зависимостями, как Security работает за кулисами — это не академическое упражнение. Это напрямую влияет на качество кода, который ты пишешь каждый день.

Возьмём конкретный пример. Аннотация @Autowired кажется магической: повесил на поле — и зависимости сами прилетают. Но если не понимать, что за этим стоит (IoC-контейнер сканирует классы, создаёт бины, инжектит зависимости), ты не сможешь разобраться, почему что-то не работает, когда приложение растёт. Или почему инъекция через конструктор считается лучшей практикой: она делает зависимости явными и позволяет тестировать класс изолированно.

То же касается Spring Security. Следуя туториалу, Онатаде столкнулся с тем, что старые примеры не работают с новыми версиями фреймворка — API изменился. Это реальная проблема в Java-экосистеме: Spring Security 5.x и 6.x заметно различаются в конфигурации. Понимание принципов (а не копипаста кода из туториала) — единственное, что позволяет адаптироваться к таким изменениям.

Что ещё происходило на неделе

Помимо теории, неделя включала и практические вещи:

• Обновление резюме. Онатаде обновил CV, чтобы отразить проекты и навыки, наработанные за предыдущие недели.
• Подача заявок на вакансии. Продолжил откликаться на позиции backend-инженера.
• Моковое интервью с AI. Попробовал пройти пробное техническое собеседование, сгенерированное нейросетью. По его словам, это стало напоминанием о том, что в технических интервью ему ещё есть куда расти.
• Подготовка к экзаменам. Параллельно готовился к университетским экзаменам.

Практический день: Spring Security в коде

На 43-й день Онатаде всё-таки вернулся к практике — прошёл туториал по Spring Security, собирая приложение параллельно с инструктором. Ключевой момент: ему пришлось адаптировать код под новую версию фреймворка, а не бездумно копировать.

В ходе работы он разобрался с UserDetailsService (сервис, который загружает данные пользователя при аутентификации), in-memory аутентификацией и разными способами инъекции зависимостей. Базу данных для полноценной аутентификации он пока не подключил — это оставил на следующую неделю.

Критический взгляд

Несколько оговорок стоит сделать.

Во-первых, формат дневника — это субъективный отчёт ученика, не профессиональное руководство. Описания вроде «изучил паттерны GoF за день» вызывают скепсис: книга «Design Patterns» Gamma, Helm, Johnson и Vlissides — это не то, что можно освоить за вечер. Скорее речь идёт о беглом ознакомлении, и это нормально — главное не путать «прочитал про паттерны» с «могу применить в реальном проекте».

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

В-третьих, Онатаде честно признаёт это. Он пишет, что «марафон — не про количество задеплоенных проектов», и что понимание принципов — часть роста. Это зрелая позиция, особенно для начинающего разработчика.

Цели на восьмую неделю

После экзаменов Онатаде планирует вернуться к активному строительству:

• Решать задачи на LeetCode для подготовки к собеседованиям
• Проходить моковые технические интервью
• Продолжить изучение Spring Security (подключение базы данных для аутентификации)
• Строить практические примеры на изученных концепциях
• Повторить структуры данных и алгоритмы
• Вернуться к изучению Python параллельно с Java
• Продолжать откликаться на вакансии backend-инженера

Что вынести из этого опыта

История Онатаде — не про Spring и не про Java. Это про фундаментальную дилемму в обучении программированию: строить или разбираться. Оба варианта важны, но на определённом этапе без «разобраться» ты упираешься в потолок: пишешь код, который работает, но не понимаешь почему. А когда перестаёт работать — не знаешь, как починить.

Возвращение к азам — это не отступление. Это инвестиция в способность быстро двигаться в будущем. Если вы тоже чувствуете, что «всё умеете, но ничего не понимаете» — возможно, пора сделать паузу и разобраться с фундаментом. Вопрос «как это работает внутри?» часто бывает полезнее, чем «как это использовать?».