🧬 Кодревью: запахи кода

Кто-то говорит, что качественный код — это субьективная вещь. Но я с этим не соглашусь.

Есть много рекомендаций и советов, которые помогают писать не просто рабочий код, но и чистый, легко читаемый и поддерживаемый.

Например, многим известные запахи кода можно эффективно использовать как для написания своего кода, так и для конструктивного кодревью. Без лишних споров и отсебятины находя компромиссы.

В этой подборке я собрал примеры:
🟣Почему комментарии — зло
🟣В чем же проблема синглтонов
🟣Как дублирование ломает жизнь
🟣Методы борьбы с надуманной сложностью
🟣И многое другое

💎 Я напоминаю, что до конца летней акции осталось пару дней.

🌿 Систем дизайн в реальной жизни: Как предлагать свои изменения

В этом посте мы разберем что такое процесс принятия решений и как внедряют и выбирают технологии в зрелых командах.

Недавно мне написали в лс и попросили совет в проблеме, что очень сложно доказывать команде какие-то архитектурные проблемы и точки роста. Разработчик хотел показать команде, что очень сложно работать без паттернов проектирования и СОЛИД принципов в проекте, но не мог найти аргументы.

Только в маленьких командах можно занести какие-то иновации или внести изменения легко. Зависимостей немного, проект небольшой. В крупных же это становится в разы сложнее. Времени на синхронизацию и кодревью съедает больше, чем на написание кода. Если твоя работа затрагивает другие команды, то нужно собрать их апрувы еще до того как напишешь код. Ибо своим желанием причинить добро ты можешь сломать всем проект.

Не нравится вам архитектура проекта, вынеси свои предъявы и предложи решения. Пора переходить на SwiftUI? Также создай обсуждение и собери аргументы почему именно он сделает жизнь лучше.

Для того, чтобы эти обсуждения были конструктивными и эффективными, а ты не бегал по сообщениям и тредам, придумали специальные процессы. Процессы принятия решений.

📺 Какие же инструменты помогают согласовать и синхронизировать изменения в реальной жизни?

Самый частый инструмент для сбора требований — это TDR.

Technical Design Review — это специальный процесс, который помогает эффективно проработать фичу, до того как ты начнешь ее кодить. Именно здесь и нужны все навыки системного дизайна.

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

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

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

Они собирают большой документ с описанной текущей проблемой, предлагаемыми решениями (чаще от 2 до 4), отмечают всех заинтересованных и получают зеленые или красные флаги для раскатки. Все в одном документе для сохранения истории и фокуса.

Только после этого можно приступать к реализациям.

Подробнее о tech design review можно почитать здесь:
- Tech Design Review в Авито
- Technical Design Review (TDR)
- Technical Design Reviews at Marfeel

💎 Вышел мок-собес по систем дизайну

Мы провели первый мок-собес. Добровольцем выступил кандидат из альфы. Задача — спроектировать главный экран инстаграма.

Мок-собес вышел крутым. Если вы хотите узнать как проходит такой формат или сталкивались с похожей задачей, то он точно будет вам полезен.

Что ожидать еще:
🟣 мок собес по платформе от разработчика из Яндекса
🟣 мок собес по систем дизайну от архитектора из Альфы

Тем самым в канале уже есть фулл хаус, где мы провели алгоритмы и задачи по iOS.

Ищу желающих провести или пройти собес доступ в канал бесплатный. Участие также бесплатное.

💎 А для остальных для доступа к закрытому каналу
нужно иметь подписку от трех месяцев на мидл или быть подписаным на мидл+

Кодревью: запахи кода ч.2

Тема запахов кода мне понравилась и я решил сделать вторую часть.

Помню, как в первых проектах мне запрещали писать оператор switch/case. А использование SOLID было не всегда хорошим решением.

Здесь я решил разобрать такие вопросы как:
🟣 Почему наследование невсегда хорошо
🟣Как важна согласованность нэйминга
🟣Магические числа

💎 Сегодня последний день летней акции

Влияет ли стресс на результативность технического собеседования?

Часто читаю блог Тимура и нахожу много полезных статей. Например, эта дает понять, как сильно отличаются разные подготовки к собесам.

Одна из моих целей когда-нибудь пройти собес в FAANG. Поэтому я много уделяю подготовки не только для реальных задач, но и для собесов. Я долго отказывался верить, что собеседования отличается от реальной жизни. Винил себя, что недостаточно опытный или скилловый. Бесспорно, это так. Но я понял, что на собеседованиях также важны навыки, которые не натренируешь на рабочих задачах.

Я думал, что будет достаточно спокойно и без спешки решать задачи и всё будет окей. А если не прошел собес, то значит просто недостаточно много решал.

Но вот очередные исследования, где доказали как стресс и сжатые условия влияют на результат.

В этом эксперименте людей разделили на две группы и заставили решать задачу у доски:
🟣В первой группе люди решали задачи в раслабленном темпе, но сильно выходили за временные рамки
🟣Во второй же группе люди решали задачи перед интервьюерами, где укладывались в сроки
🟣Первая группа находила более оптимальные решения.
🟣Результаты тех, кто провалил задачи в первой группе равны 36.3%, а во второй аж 61.5%.

Охереть. Я догадывался, что стресс сильно дебафает, но не настолько.

🌋О чем это говорит?

Как минимум, что навыки решения задач сильно падают при реальном собеседовании и что недостаточно просто соло решать литкод, закрывшись в четырех стенах. А решение тысяч задач на платформах не гарантирует успех.

Такие статьи корректируют планы развития. Обесценивает просто сборники задач как литкод, голые задачи и кол-во решение. Показывают, насколько же важно окружение и практика в боевых условиях. Необходимые условия и контексты.

Нужно работать над психологическим состоянием и уметь контролировать стресс. Эта же проблема была очень часто и в спорте, когда множество ребят отлично показывают себя на тренировках, но теряются на соревнованиях.

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