Процесс и методологии
Гибкие методологии (Scrum, Kanban), соглашения о коде и практики код-ревью.
7 вопросов
MiddleТеорияОчень частоОбъясните принципы DRY, KISS и YAGNI.
Объясните принципы DRY, KISS и YAGNI.
DRY: каждое знание имеет единственное авторитетное представление. KISS: выбирайте простейший работающий дизайн. YAGNI: избегайте спекулятивных абстракций.
Типичные ошибки
- ✗Применять DRY слишком агрессивно — случайное сходство — не то же самое, что одна концепция; их слияние связывает несвязанные concern-ы (WET — Write Everything Twice — иногда верно)
- ✗Путать KISS с 'никаких абстракций' — уместные абстракции снижают сложность; KISS направлен против случайной сложности, а не необходимой
- ✗Использовать YAGNI для обоснования отказа от тестов или обработки ошибок — YAGNI применяется к функциям и гибкости дизайна, а не к корректности и надёжности
Уточняющие вопросы
- →Когда WET (Write Everything Twice) код даёт лучшие результаты, чем агрессивный DRY?
- →Как сбалансировать DRY и YAGNI при проектировании публичного API для библиотеки?
JuniorТеорияЧастоЧто такое качество кода? Назовите измеримые показатели.
Что такое качество кода? Назовите измеримые показатели.
Качество кода — насколько легко его понимать, изменять и проверять. Измеримые показатели: цикломатическая сложность, покрытие тестами, плотность дефектов, предупреждений статанализа на kloc, среднее время прохождения код-ревью.
Типичные ошибки
- ✗Сводить качество кода к одному числу — это набор измерений (читаемость, тестируемость, производительность, надёжность)
- ✗Оптимизировать только одну метрику — высокое покрытие при слабом качестве тестов или низкая сложность при нечитаемом коде
- ✗Игнорировать качественные сигналы — боли, поднятые на ревью, реальны, даже когда ни одна метрика их не подсвечивает
Уточняющие вопросы
- →Как балансировать метрики качества кода и дедлайны?
- →Чем различаются качество кода, технический долг и поддерживаемость?
MiddleТеорияЧастоКаковы принципы итеративных методологий (Scrum/Kanban)?
Каковы принципы итеративных методологий (Scrum/Kanban)?
Agile доставляет ценность инкрементально и адаптируется. Scrum использует фиксированные спринты с ролями и церемониями; Kanban — непрерывный поток с WIP-лимитами.
Типичные ошибки
- ✗Воспринимать Agile как 'никакого планирования' — Agile ценит реагирование на изменения, а не игнорирование планов; долгосрочное планирование с точками корректировки по-прежнему ценно
- ✗Превращение ежедневного standup в отчёт о статусе — он должен выявлять блокеры и синхронизировать участников команды, а не быть отчётом о прогрессе руководителю
- ✗Рассматривать скорость спринта как показатель производительности — скорость измеряет мощность для планирования, а не продуктивность; сравнение скорости команд бессмысленно
Уточняющие вопросы
- →Чем Definition of Done (DoD) отличается от критериев приёмки?
- →Когда система Kanban более подходит, чем Scrum для команды разработки?
MiddleТеорияЧастоЧто такое побочные эффекты, идемпотентность и чистые функции?
Что такое побочные эффекты, идемпотентность и чистые функции?
Побочный эффект — любое наблюдаемое изменение вне функции. Чистая функция детерминирована и без побочных эффектов; её легко тестировать и кэшировать. Идемпотентность — f(f(x))==f(x) (HTTP PUT).
Типичные ошибки
- ✗Считать const-методы чистыми — const-метод может вызывать
std::rand(), делать I/O или записывать вmutable-члены;constтолько предотвращает изменениеthis - ✗Предполагать, что идемпотентный = чистый — идемпотентные операции могут иметь побочные эффекты (удаление ресурса идемпотентно: второй вызов — no-op, но первый изменил состояние)
- ✗Игнорировать идемпотентность в логике повторных попыток — повторение не-идемпотентной операции (напр., списание с кредитной карты) при сетевом сбое вызывает двойное выполнение
Уточняющие вопросы
- →Как работает мемоизация в C++ и когда она выгодна?
- →Каковы преимущества чисто функционального дизайна для конкурентного кода?
SeniorТеорияЧастоНа что обращать внимание при code review?
На что обращать внимание при code review?
Code review проверяет корректность, безопасность памяти и потоков, обработку ошибок, производительность, читаемость имён, соответствие дизайну и покрытие тестами.
Типичные ошибки
- ✗Сосредотачиваться только на стиле — форматирование для линтеров; ревьюеры должны фокусироваться на корректности, дизайне и поддерживаемости
- ✗Аппрувить большие PR без понимания всех изменений — разбивайте PR на меньшие проверяемые единицы; если не можете понять — скажите об этом
- ✗Быть чрезмерно директивным — предлагайте улучшения с обоснованием, а не командами; 'рассмотрите X потому что Y' лучше, чем 'сделайте X'
Уточняющие вопросы
- →Как обращаться с PR, где вы не согласны с подходом к дизайну автора?
- →Каков идеальный размер PR и почему это важно для качества ревью?
MiddleТеорияИногдаПреимущества и недостатки соглашений о кодировании.
Преимущества и недостатки соглашений о кодировании.
Конвенции снижают когнитивную нагрузку, делают код искабельным, могут авто-применяться (clang-format) и прекращают споры о стиле. Минусы: затраты на договорённость, жёсткость и миграция legacy.
Типичные ошибки
- ✗Дебатировать табы vs пробелы на code review вместо одноразового командного решения — зафиксируйте
.clang-formatоднажды и автоматизируйте в CI - ✗Иметь документ с конвенциями, который никто не читает — поместите
.clang-formatи.clang-tidyв корень репозитория; автоматическое соблюдение лучше документации - ✗Применять конвенции задним числом вместе с изменениями логики — изменения стиля должны быть отдельными коммитами для читаемости диффов
Уточняющие вопросы
- →Как настроить clang-format для соблюдения стиля команды и запускать его в CI?
- →Какова позиция Google C++ Style Guide по исключениям и почему она спорна?
MiddleТеорияИногдаПреимущества и недостатки функционального подхода vs ООП.
Преимущества и недостатки функционального подхода vs ООП.
ООП инкапсулирует изменяемое состояние, но страдает от разделяемого состояния и хрупких иерархий. FP использует чистые функции и неизменяемые данные — легко тестировать, но дорогие копии. C++ их совмещает.
Типичные ошибки
- ✗Рассматривать FP и OOP как взаимоисключающие — большинство production C++ кода является их смесью; дихотомия искусственная
- ✗Слепо применять FP-паттерны (напр., глубокие цепочки
std::transform) когда простой цикл понятнее — читаемость важнее чистоты парадигмы - ✗Игнорировать разницу в производительности — неизменяемые данные в FP означают копии; в C++ это имеет реальную стоимость; используйте
move-семантику и представления (std::ranges::views) для избежания копий
Уточняющие вопросы
- →Как библиотека ranges в C++20 приносит функциональные конвейеры в C++ без копирования?
- →Что такое монадическая обработка ошибок (цепочки
std::expected,std::optional) и как она сравнивается с исключениями?
