README
- Java 25 LTS — основной язык разработки
- Gradle 8.x — система сборки (через Gradle Wrapper)
- Checkstyle — статический анализ стиля кода
- Конфигурация:
config/checkstyle/checkstyle.xml - Запуск:
./gradlew checkstyleMain
- Конфигурация:
- JUnit 5 — фреймворк тестирования
- Запуск:
./gradlew test
- Запуск:
- GitHub Actions — автоматическая проверка PR
- Checkstyle на каждый коммит
- Тесты на каждый коммит
- Конфигурация:
.github/workflows/
- Стиль: Google Java Style Guide (через Checkstyle)
- Коммиты: Conventional Commits (
feat:,fix:,docs:) - Ветки:
feature/DVT-Xдля задач,master— основная - Pull Request: обязателен для слияния в master
Запустить задачи Gradle:
Gradle Tool Window: откройте (View → Tool Windows → Gradle), дважды кликните run, build, test.
Run Anything (Ctrl + Ctrl): введите поочерёдно gradle run, gradle build, gradle test → Enter.
ru.mentee.power — пакет для управления данными менти: хранение имени, номера спринта, плановых часов и проверка готовности к спринту.
Поле - Описание
menteeName - Имя менти (строка).
sprintNumber - Номер текущего спринта (целое число).
plannedHoursPerWeek - Плановые часы в неделю (число с плавающей точкой).
readyForSprint() - Метод-проверка: возвращает true, если plannedHoursPerWeek > 0 и sprintNumber > 0, иначе false.
- Откройте Gradle Tool Window (View → Tool Windows → Gradle)
- Выполните: devtools → Tasks → application → run
- Ожидаемый вывод в Run Tool Window: Суммарно: пройдено 25 из 36 уроков, осталось 11 уроков
- Откройте Gradle Tool Window
- Выполните: devtools → Tasks → verification → test
- Ожидаемый вывод: BUILD SUCCESSFUL, все тесты зелёные
- Установите breakpoint на строке цикла while в ProgressTracker.calculateProgress
- Запустите Debug: кликните правой кнопкой на main → Debug 'ProgressTracker.main()'
- Используйте Step Over (F8) для прохождения итераций
- Проверьте Variables: counter, remainingHours должны изменяться корректно
- Используйте Evaluate Expression (Alt+F8): вычислите remainingLessons * 2
- Ожидаемый результат Evaluate: 14 (для completedLessons=5, totalLessons=12)
- Если вывод некорректен: проверьте логику цикла через Debug
- Если тесты красные: откройте вывод теста, найдите AssertionError, скорректируйте метод
- Если Debug не останавливается: убедитесь, что breakpoint установлен (красный кружок)
Проект следует правилам Google Java Style Guide с адаптацией. Автоматическая проверка: ./gradlew checkstyleMain
До: public void add_student(Student s) { } После: public void addStudent(Student student) { }
Почему: Java Convention требует camelCase для методов. Источник: https://google.github.io/styleguide/javaguide.html#s5.3-camel-case
До: if(condition) { После: if (condition) {
Почему: улучшает читаемость, отделяет ключевое слово от выражения. Источник: Oracle Code Conventions — Whitespace
До: public List getStudentsFromSpecificCityWithVeryLongName... После: public List getStudentsByCity(String city) {
Почему: длинные строки затрудняют чтение в редакторе и при code review. Источник: https://google.github.io/styleguide/javaguide.html#s4.4-column-limit
До: import java.util.List; import java.util.ArrayList; import java.io.File; После: import java.io.File; import java.util.ArrayList; import java.util.List;
Почему: алфавитный порядок упрощает поиск импортов. Источник: IntelliJ IDEA → Code → Optimize Imports
До: if (condition) doSomething(); После: if (condition) { doSomething(); }
Почему: скобки обязательны даже для однострочных блоков. Источник: https://google.github.io/styleguide/javaguide.html#s4.1.1-braces-always-used
Используйте этот чеклист для само-ревью перед запросом ревью у ментора:
- Код решает поставленную задачу полностью
- Обработаны граничные случаи (null, пустые данные, экстремальные значения)
- Обработка ошибок реализована корректно
- Добавлены тесты для нового функционала (или обновлены существующие)
- Все тесты проходят локально:
./gradlew test - Покрыты позитивные и негативные сценарии
- JaCoCo coverage ≥ 80% для нового кода
- Имена переменных, методов и классов отражают назначение
- Нет дублирования кода (DRY principle)
- Checkstyle проходит без ошибок:
./gradlew checkstyleMain - Нет закомментированного кода или отладочного вывода (
System.out.println)
- README обновлён (если добавлена новая функциональность)
- Публичные методы имеют JavaDoc (если применимо)
- Примеры использования актуальны
- Runbook обновлён (если изменились команды запуска/проверки)
- Нет очевидных проблем производительности
- Нет хардкода паролей, токенов или конфиденциальных данных
Пример 1:
Проблема: Метод calculateDiscount (строка 45) имеет 3 вложенных if-else и 40 строк.
Почему это важно: Сложная логика плохо тестируется и тяжело поддерживается.
Предложение: Вынести каждое условие в отдельный метод (например, isEligibleForBonusDiscount())
и использовать паттерн Strategy для разных типов скидок.
Пример 2:
Проблема: Тест testProcessOrder (строка 78) проверяет только успешный сценарий.
Почему это важно: Не проверена обработка ошибок при недостаточном балансе.
Предложение: Добавить тест testProcessOrder_InsufficientBalance_ThrowsException()
с использованием assertThatThrownBy().
Пример 1:
Этот код ужасен, полностью переписать.
Почему плохо: Нет конкретики (что именно плохо), нет предложения (как исправить), токсичный тон (демотивирует автора).
Пример 2:
Здесь лучше использовать Stream API.
Почему плохо: Нет объяснения почему лучше, нет примера как переписать, неясно какую проблему это решает.
Файл: README.md (начало файла) Проблема: Нет бейджа статуса сборки GitHub Actions Почему важно: CI badge показывает статус проекта сразу при открытии README — это стандарт для open-source проектов и упрощает мониторинг состояния сборки. Исправление: Добавить бейдж в начало README:
Файл: src/main/java/ru/mentee/progress/ProgressTracker.java (строка 20)
Проблема: Оставлен System.out.println("Debug: starting loop")
Почему важно: Отладочный вывод замусоривает логи production-приложения и создаёт впечатление небрежности.
Исправление: Удалить строку или заменить на logger (если логирование настроено).
Файл: src/main/java/ru/mentee/progress/ProgressTracker.java (строки 20) Проблема: пустой TODO оставлен на строке без пояснения Почему важно: Комментарий создаёт путаницу: непонятно зачем он сохранён и актуален ли. Если нужна история изменений — она в Git. Исправление: Удалить комментарий. Если нужна старая версия — посмотреть в Git History.
| № | Запрос | Операторы | Официальный источник | Альтернатива | Статус | Дата проверки |
|---|---|---|---|---|---|---|
| 1 | Lombok Gradle Short | site:search.maven.org "lombok" OR site:mvnrepository.com "lombok" | https://search.maven.org/artifact/org.projectlombok/lombok/1.18.30/jar | https://mvnrepository.com/artifact/org.projectlombok/lombok/1.18.30 | 200 OK | 04.03.2026 |
| 2 | Java Stream API | site:docs.oracle.com "stream api" intitle:api java 25 | https://docs.oracle.com/en/middleware/standalone/coherence/15.1.1/develop-applications/using-repository-api.html | https://blog.jetbrains.com/idea/2025/09/java-25-lts-and-intellij-idea/ | 200 OK | 04.03.2026 |
| 3 | горячие клавиши IntelliJ IDEA | site:www.jetbrains.com/help "keymap" "intellij idea" | https://www.jetbrains.com/help/idea/settings-keymap.html | PDF keymap JetBrains | 200 OK | 04.03.2026 |
Задача: Нужно добавить валидацию email в класс Student Контекст: Java 25, у меня есть класс Student с полем email (String), проект на Gradle Ограничения: без использования регулярных выражений на данном этапе, простая проверка наличия @ и точки Ожидаемый результат: план из 3-5 шагов, объяснение "почему именно так", НЕ пиши код — я реализую сам Критерии успеха: валидация отклоняет пустые строки, строки без @, строки без точки после @
**AI-1 ([Яндекс Алиса]): План реализации валидации email в классе Student Шаг 1. Определить метод валидации
Создайте отдельный приватный метод в классе Student для проверки корректности email — например, isValidEmail(String email).
Почему так:
Логика валидации будет изолирована от остальной логики класса — это улучшит читаемость и поддерживаемость кода.
Метод можно будет легко протестировать отдельно (например, в юнит‑тестах).
При необходимости в будущем можно будет расширить или заменить логику валидации без изменения других частей класса.
Шаг 2. Реализовать базовые проверки в методе
В методе isValidEmail последовательно проверьте:
Не является ли строка null или пустой ("").
Содержит ли строка символ @.
Есть ли хотя бы одна точка (.) после символа @.
Почему именно эти условия:
Проверка на null и пустую строку гарантирует, что email заполнен — соответствует критерию успеха.
Наличие @ — обязательное условие для email‑адреса.
Точка после @ помогает отсеять некорректные форматы (например, user@domain без домена верхнего уровня).
Почему без точки до @: Требование не оговаривает проверку части до @, а избыточные ограничения могут блокировать валидные адреса (например, короткие локальные части).
Шаг 3. Интегрировать валидацию в сеттер
Добавьте вызов метода isValidEmail в сеттер поля email (setEmail(String email). Если валидация не пройдена, выбросьте исключение — например, IllegalArgumentException с понятным сообщением об ошибке.
Почему так:
Валидация выполняется при каждом изменении email — данные в объекте всегда корректны.
Исключение сразу сигнализирует о проблеме, что упрощает отладку.
Сеттер — стандартное место для валидации в Java‑бинах (POJO).
Шаг 4. Обеспечить валидацию при создании объекта
Если в классе Student есть конструктор, принимающий email, добавьте в него ту же проверку (вызов isValidEmail) с выбросом исключения при ошибке.
Почему так:
Гарантирует корректность email даже при инициализации объекта — данные валидны с момента создания.
Исключает ситуацию, когда объект создаётся с некорректным email, а ошибка всплывает позже.
Поддерживает принцип «fail‑fast»: ошибка обнаруживается сразу, а не при последующем вызове сеттера.
Шаг 5. Подготовить тестовые сценарии
Составьте набор тестовых данных для проверки работы валидации:
Валидные email: user@example.com, test@domain.org.uk.
Невалидные email:
пустая строка ("") и null;
без @: userexample.com;
без точки после @: user@domain;
только @: @.
Почему это важно:
Подтверждает, что валидация работает по всем критериям успеха.
Помогает выявить краевые случаи (например, @domain.com или user@.com), которые могут потребовать уточнения логики.
Служит основой для написания юнит‑тестов — можно автоматизировать проверку всех сценариев.
Итог: План обеспечивает:
соответствие критериям успеха (отклонение пустых строк, строк без @, без точки после @);
чистоту и тестируемость кода за счёт изоляции логики валидации;
надёжность данных в объекте Student (валидация при создании и изменении);
возможность быстрого выявления ошибок через исключения;
основу для дальнейшего тестирования и расширения (например, добавления regex‑валидации позже).**
**AI-2 ([DeepSeek]): Вот план добавления валидации email в класс Student:
Шаг 1: Создание метода validateEmail Создайте приватный статический метод, который принимает String и возвращает boolean. Разместите его рядом с полями класса — это сохранит инкапсуляцию логики валидации. Метод должен быть статическим, чтобы его можно было использовать до создания объекта.
Шаг 2: Проверка на null и пустую строку Первым делом проверьте, что строка не null и не пустая после trim(). Это базовое требование — email не может быть пустым. Используйте trim() для отсечения пробелов, так как " " технически не является валидным email.
Шаг 3: Поиск символа @ Найдите позицию символа '@' в строке. Если его нет — валидация не пройдена. Это минимальное требование к структуре email. Запомните эту позицию для следующего шага.
Шаг 4: Проверка наличия точки после @ Убедитесь, что после позиции '@' есть хотя бы одна точка. При этом точка не должна быть сразу после @ (нужен хотя бы один символ между ними) и не должна быть последним символом. Это проверяет наличие домена второго уровня.
Шаг 5: Интеграция в конструктор/setter Добавьте вызов validateEmail в конструктор и setter. Если валидация не пройдена — выбрасывайте IllegalArgumentException с понятным сообщением. Это гарантирует, что объект всегда будет в валидном состоянии.
Почему именно так: Такой подход обеспечивает постепенное наращивание сложности проверок, изолирует логику валидации в одном месте и гарантирует целостность объекта при создании и модификации.**
Сравнение: Яндекс дал более полный ответ. Ответил развёрнуто на некоторые вопросы, которые не были заданы в промпте. DeepSeek дал более краткий и лаконичный ответ, но на все необходимые вопросы ответил. В остальном, ответы были практически одинаковыми.
Код для проверки: public record Mentee( String name, String city, String goal, int completedLessons, int totalLessons ) { public Mentee { if (completedLessons < 0 || totalLessons <= 0 || completedLessons > totalLessons) { throw new IllegalArgumentException("Некорректные значения прогресса"); } } }
Что проверить:
- Логические ошибки
- Соответствие Code Conventions
- Производительность
**AI-1 ([Яндекс Алиса]): 1. Логические ошибки
В коде обнаружены следующие проблемы:
Ошибка 1. Некорректное имя исключения
В коде используется IllegalArgumentException, но правильное имя класса — IllegalArgumentException (опечатка в написании: IllegalArgumentException → IllegalArgumentException).
Ошибка 2. Неверная логика проверки totalLessons
Условие totalLessons <= 0 запрещает нулевое значение, но не учитывает, что totalLessons может быть отрицательным. Правильнее проверять totalLessons < 0, а затем уже запрещать totalLessons == 0, если это действительно недопустимо.
Ошибка 3. Отсутствие валидации других полей
Поля name и city не проверяются на null или пустую строку, что может привести к ошибкам в дальнейшем использовании объекта.
Ошибка 4. Синтаксическая ошибка в объявлении компактного конструктора
Синтаксис public Mentee { некорректен. В Java для записи (record) компактный конструктор объявляется без модификатора доступа — просто Mentee {.
-
Соответствие Code Conventions
Нарушения стандартов оформления:
Отступы и форматирование. Код не имеет последовательных отступов, что ухудшает читаемость.
Пробелы вокруг операторов. Отсутствуют пробелы вокруг операторов сравнения и логических операторов.
Расположение фигурных скобок. Открывающая скобка находится на той же строке, что и объявление конструктора, а закрывающая — на отдельной строке без должного отступа.
Сообщения об ошибках. Текст исключения не содержит конкретных данных о том, какое именно поле некорректно. Лучше указывать детали.
- Производительность
В данном случае производительность не является проблемой, поскольку:
это простая валидация данных при создании объекта;
операции сравнения выполняются за константное время O(1);
нет циклов, рекурсии или ресурсоёмких операций;
записи (record) в Java оптимизированы для хранения данных.
Однако стоит отметить, что валидация выполняется при каждом создании объекта. Это незначительно, но всё же влияет на производительность при массовом создании объектов.
**
**AI-2 ([DeepSeek]): 1. Логические ошибки
Потенциальная проблема с totalLessons <= 0:
Условие totalLessons <= 0 запрещает создание записи с totalLessons = 0
Но если курс новый и уроков ещё нет, totalLessons = 0 — это валидное состояние
При этом completedLessons > totalLessons всё равно защитит от некорректных значений
Рекомендация: изменить на totalLessons < 0
Отсутствует проверка строк:
name, city, goal могут быть null или пустыми
В контексте валидации данных это может быть проблемой
-
Code Conventions
Нарушения:
Отсутствуют Javadoc-комментарии для record и конструктора
Магические строки в исключении — лучше вынести в константу или сделать более информативное сообщение с указанием значений
Параметры конструктора не имеют final модификатора (хотя в компактном синтаксисе это простительно)
- Производительность
Всё отлично:
Проверки выполняются за O(1)
Нет создания лишних объектов
Компактный конструктор record работает эффективно**
Сравнение: Яндекс как всегда дал более подробный ответ, нашёл больше ошибок. Яндекс заметил некорректное имя исключения и синтаксическую ошибку в объявлении компактного конструктора. DeepSeek этого не заметил, жалобы на производительность были примерно одинаковыми, так как код небольшой.
Каждый термин содержит:
- RU / EN — русское и английское название
- Определение — краткое (1-2 предложения) объяснение термина
- Контекст использования — где и когда применяется
- Пример — конкретное применение в коде/команде/документации
- Источник — ссылка на официальную документацию
Определение: Development environment for building applications using the Java programming language. Includes compiler (javac), archiver (jar), documentation generator (javadoc), and other tools.
Контекст использования: JDK необходим для компиляции Java-кода в байт-код и создания исполняемых JAR-файлов. Без JDK невозможно собрать Java-проект.
Пример: После установки JDK выполняем java -version для проверки версии. В IntelliJ IDEA настраиваем Project SDK: File → Project Structure → Project → SDK → выбираем JDK 25.
Источник: https://docs.oracle.com/en/java/javase/21/docs/
Определение: Набор компонентов для запуска Java‑приложений. Включает виртуальную машину Java (JVM) и стандартные библиотеки классов, но не содержит инструментов разработки.
Контекст использования: JRE устанавливают на компьютеры конечных пользователей, чтобы запускать готовые Java‑программы (например, приложения или апплеты в браузере). Без JRE выполнение Java‑кода невозможно.
Пример: Пользователь скачивает и устанавливает JRE, чтобы запустить десктопное Java‑приложение (например, Minecraft или Apache OpenOffice). В командной строке можно проверить версию: java -version.
Источник: https://www.oracle.com/java/technologies/javase/jre-index.html
RU / EN: Git / Гит
Определение: Распределённая система контроля версий, позволяющая отслеживать изменения в файлах и координировать работу нескольких разработчиков над одним проектом.
Контекст использования: Git применяют в разработке ПО для ведения истории изменений кода, создания веток для новых функций, слияния изменений от разных разработчиков и отката к предыдущим версиям при необходимости.
Пример: Пример: Разработчик выполняет команды:
git clone https://github.com/user/repo.git # клонирование репозитория git add . # добавление изменений в индекс git commit -m "Fix bug in login" # создание коммита git push origin main # отправка изменений на сервер
Источник: https://git-scm.com/doc
RU / EN: Рецензирование кода / Code Review
Определение: Процесс проверки исходного кода другим разработчиком с целью выявления ошибок, улучшения качества кода и обмена знаниями в команде.
Контекст использования: Code review проводят перед слиянием новой функциональности в основную ветку проекта (например, в рамках Pull Request на GitHub/GitLab). Это стандартная практика в Agile и DevOps.
Пример: Разработчик создаёт Pull Request в GitHub. Коллеги проверяют код, оставляют комментарии (например, «переименовать переменную x в userCount») и одобряют изменения. После устранения замечаний код вливается в ветку main.
RU / EN: Java Virtual Machine / Виртуальная машина Java
Определение: Виртуальная машина, выполняющая байт‑код Java‑программ. Обеспечивает кроссплатформенность (принцип Write Once, Run Anywhere) за счёт интерпретации байт‑кода в машинные инструкции конкретной платформы. Включает загрузчик классов, механизм выполнения и сборщик мусора (Garbage Collector).
Контекст использования: JVM запускается при старте любой Java‑программы — будь то десктопное приложение, серверный бэкенд или Android‑приложение (в модифицированной версии ART). Она:
загружает классы в память;
проверяет безопасность байт‑кода;
интерпретирует или компилирует байт‑код (с помощью JIT‑компилятора);
управляет памятью (автоматически освобождает неиспользуемые объекты).
JVM используется везде, где нужно запускать Java‑код: на серверах, ПК, мобильных устройствах и встраиваемых системах.
Пример: Пример:
Запуск простой Java‑программы:
java HelloWorld
Здесь java — команда, запускающая JVM, которая:
находит и загружает класс HelloWorld;
выполняет метод main;
при необходимости применяет JIT‑оптимизации для ускорения кода.
RU / EN: Gradle Wrapper / Обертка Gradle
Определение: Набор скриптов и конфигурационных файлов, позволяющий запускать сборки Gradle без предварительной установки системы сборки на компьютере. Gradle Wrapper автоматически скачивает и использует указанную в проекте версию Gradle, гарантируя единообразие окружения у всех участников команды.
Контекст использования: Gradle Wrapper применяют в проектах на Gradle для:
обеспечения одинаковой версии Gradle у всех разработчиков и на CI/CD‑серверах;
исключения проблем из‑за разных версий Gradle на локальных машинах;
упрощения настройки окружения (не нужно вручную устанавливать Gradle);
воспроизводимости сборок в любой среде (локально, в облаке, на серверах непрерывной интеграции).
Пример: Пример:
Генерация Wrapper в существующем проекте:
gradle wrapper --gradle-version 8.10
Основные файлы Wrapper после генерации:
gradlew # скрипт для Linux/macOS
gradlew.bat # скрипт для Windows
gradle/wrapper/
gradle-wrapper.jar # JAR‑файл загрузчика
gradle-wrapper.properties # конфигурация (версия Gradle и URL дистрибутива)
RU / EN: Инструмент сборки / Build Tool
Определение: Программа для автоматизации процесса создания исполняемых приложений из исходного кода. Инструмент сборки выполняет компиляцию, управление зависимостями, упаковку кода, запуск тестов и развёртывание — превращая исходные файлы в готовый к использованию продукт.
Контекст использования: Build Tool применяют на всех этапах разработки ПО:
в небольших проектах — для стандартизации процесса сборки;
в крупных проектах — чтобы избежать ошибок ручной компиляции и упорядочить сложные цепочки зависимостей;
в командах разработчиков — для обеспечения единообразия сборок у всех участников;
в CI/CD‑пайплайнах (Jenkins, GitHub Actions и т. д.) — для автоматического тестирования и деплоя при каждом коммите;
при публикации библиотек и фреймворков — для генерации артефактов (JAR, NPM‑пакетов и пр.) и их публикации в репозиториях.
Пример: Пример:
Apache Maven (для Java):
Конфигурационный файл pom.xml с описанием зависимостей и плагинов.
Команды:
mvn compile # компиляция кода
mvn test # запуск тестов
mvn package # упаковка в JAR
mvn deploy # публикация в репозиторий
Источник:
https://maven.apache.org/guides/
RU / EN: Интегрированная среда разработки / Integrated Development Environment (IDE)
Определение: Комплексная программа для разработки программного обеспечения, объединяющая в одном интерфейсе инструменты написания, тестирования, отладки и сборки кода. Включает редактор кода с подсветкой синтаксиса и автодополнением, компилятор/интерпретатор, отладчик, инструменты управления проектами и интеграции с системами контроля версий.
Контекст использования: IDE применяют на всех этапах создания ПО:
при написании кода (с использованием подсказок, шаблонов и автодополнения);
для быстрого переключения между файлами большого проекта;
при поиске и исправлении ошибок (с помощью отладчика и анализатора кода);
для запуска и тестирования приложений прямо из среды разработки;
для сборки проекта (компиляции, упаковки в исполняемые файлы);
при работе с Git и другими системами контроля версий (совершение коммитов, переключение веток);
для развёртывания приложений (деплоя на серверы или в облачные платформы);
в обучении программированию (наглядность и готовые настройки упрощают старт).
Пример: Пример:
IntelliJ IDEA (для Java/Kotlin):
открытие проекта: File → Open;
написание кода с автодополнением (например, ввод sysout → разворачивается в System.out.println());
запуск теста: клик правой кнопкой мыши на методе → Run ‘testName’;
отладка: установка точек останова (breakpoints), пошаговое выполнение кода, просмотр значений переменных.
RU / EN: Комплект для разработки программного обеспечения / Software Development Kit (SDK)
Определение: Набор инструментов, библиотек, документации и примеров кода для создания приложений под конкретную платформу, язык программирования или сервис. SDK упрощает разработку, предоставляя готовые компоненты и стандартизированные способы взаимодействия с целевой средой.
Контекст использования: SDK применяют для:
разработки мобильных приложений (Android SDK, iOS SDK);
создания веб‑приложений с интеграцией сторонних сервисов (например, SDK платёжных систем);
работы с облачными платформами (AWS SDK, Google Cloud SDK);
разработки игр (Unity SDK, Unreal Engine SDK);
интеграции функций в существующие приложения (карты, аналитика, реклама);
ускорения разработки за счёт готовых библиотек и шаблонов;
обеспечения совместимости приложения с целевой платформой и её версиями.
Пример: Пример:
Android SDK (для разработки под Android):
включает эмулятор устройства для тестирования;
предоставляет библиотеки для работы с UI, сетью, хранилищем;
содержит инструменты сборки (aapt, dx) и отладки (ADB);
пример использования библиотеки для отображения карты:
java MapView mapView = findViewById(R.id.map_view); mapView.getMapAsync(this); // вызов метода из Google Maps SDK
Источник: https://developer.android.com/tools/sdk
RU / EN: Репозиторий / Repository
Определение: Хранилище данных (чаще всего — исходного кода), содержащее файлы проекта, историю их изменений и метаданные. Репозиторий позволяет отслеживать версии, координировать совместную работу и восстанавливать предыдущие состояния проекта.
Контекст использования: Репозитории применяют для:
хранения исходного кода программных проектов;
ведения истории изменений (кто, когда и что изменил);
организации совместной работы нескольких разработчиков;
создания веток разработки (feature branches) для параллельной работы над разными функциями;
резервного копирования кода и защиты от потери данных;
публикации открытого исходного кода (open‑source проекты);
автоматизации сборки и тестирования через интеграцию с CI/CD‑системами;
управления зависимостями и артефактами (в пакетных репозиториях).
Пример: Пример:
Локальный Git‑репозиторий:
создание нового репозитория в папке проекта:
git init
добавление файлов и создание первого коммита:
git add .
git commit -m "Initial commit"
Источник: https://git-scm.com/doc
RU / EN: Коммит / Commit
Определение: Фиксация изменений в репозитории системы контроля версий (например, Git). Коммит создаёт «снимок» состояния проекта на определённый момент времени, сохраняет внесённые изменения и добавляет их в историю репозитория. Каждый коммит имеет уникальный идентификатор (хеш), метаданные (автор, дата) и сообщение с описанием изменений.
Контекст использования: Коммиты применяют для:
поэтапной фиксации изменений в коде (каждая логическая группа правок — отдельный коммит);
ведения истории разработки (возможность отследить, кто, когда и зачем вносил изменения);
упрощения отладки (поиск момента появления ошибки через историю коммитов);
совместной работы в команде (обмен изменениями через удалённый репозиторий);
создания контрольных точек для отката к стабильным версиям;
ревью кода (анализ отдельных коммитов перед слиянием в основную ветку);
автоматизации CI/CD‑пайплайнов (запуск тестов и деплоя на основе новых коммитов).
Пример: Пример:
Стандартный цикл создания коммита в Git:
проверка статуса репозитория:
git status
добавление изменённых файлов в индекс (staging area):
git add src/main/java/MyClass.java
или все изменённые файлы:
git add .
создание коммита с описанием изменений:
git commit -m "Add user authentication feature"
Источник: https://git-scm.com/docs
RU / EN: Ветка / Branch
Определение: Независимая линия разработки в системе контроля версий (например, Git), которая ссылается на конкретный коммит и позволяет вносить изменения в проект изолированно от других веток. Ветка — это лёгкий указатель на коммит; при создании новых коммитов указатель ветки автоматически перемещается вперёд.
Контекст использования: Ветку создают для:
разработки новой функциональности (feature branch) без влияния на стабильную версию кода;
исправления ошибок (hotfix branch) в продакшн‑версии;
экспериментов с новыми идеями (экспериментальные ветки);
подготовки релизов (release branch) с финальной стабилизацией кода;
параллельной работы нескольких разработчиков над разными задачами;
изоляции нестабильного кода до его тестирования и ревью;
реализации workflow‑моделей (Gitflow, GitHub Flow и др.).
Пример: Пример:
Создание и переключение на новую ветку (для разработки функции):
git branch new-feature # создание ветки
git checkout new-feature # переключение на неё
или одной командой:
git checkout -b new-feature
RU / EN: Запрос на внесение изменений (запрос на слияние) / Pull Request (PR)
Определение: Механизм в системах контроля версий (GitHub, GitLab, Bitbucket), позволяющий предложить изменения из одной ветки репозитория в другую (обычно — из функциональной ветки в основную). PR включает обзор кода (code review), обсуждение правок, проверку автоматизированных тестов и процесс слияния одобренных изменений.
Контекст использования: Pull Request применяют для:
внесения изменений в проекты с открытым исходным кодом (open‑source) через модель Fork + Pull: участник форкает репозиторий, вносит правки и отправляет PR в оригинальный проект;
организации совместной работы в командах: разработчики создают ветки для задач, отправляют PR и проходят ревью перед слиянием в основную ветку;
проверки качества кода: коллеги оставляют комментарии, предлагают оптимизации, выявляют ошибки;
запуска автоматизированных проверок (CI/CD): тесты, линтеры, сканирование уязвимостей выполняются при создании PR;
документирования изменений: история PR хранит обсуждения, причины решений и связь с задачами в трекере (например, Jira);
контроля доступа: только уполномоченные пользователи могут одобрять и сливать PR в защищённые ветки (main, develop).
Пример: Пример:
Создание Pull Request на GitHub:
разработчик завершил работу в ветке feature/new-login и отправил её на сервер:
git push origin feature/new-login
на странице репозитория GitHub нажимает кнопку New Pull Request;
выбирает целевую ветку (base: main) и исходную (compare: feature/new-login);
заполняет шаблон:
заголовок: feat: add user login with OAuth;
описание:
markdown
Реализована авторизация через Google и GitHub.
Что сделано:
- добавлен компонент формы входа;
- настроена интеграция с OAuth‑провайдерами;
- написаны юнит‑тесты (покрываемость 85 %).
Fixes #42
назначает ревьюеров и метки (review/needed, bugfix).
Источник: https://docs.github.com/en/pull-requests
RU / EN: Checkstyle / Checkstyle
Определение: Статический анализатор кода для языка Java, проверяющий соответствие исходного кода заданным правилам оформления и стиля. Инструмент выявляет отклонения от стандартов (например, Google Java Style Guide или Sun Code Conventions), а также потенциальные проблемы качества кода. Работает на основе анализа AST (Abstract Syntax Tree).
Контекст использования: Checkstyle применяют для:
обеспечения единообразия кода в команде (отступы, скобки, именование);
автоматизации проверок стиля на этапе сборки проекта (Maven, Gradle);
интеграции в IDE (IntelliJ IDEA, Eclipse) для мгновенной обратной связи при написании кода;
включения в CI/CD‑пайплайны (Jenkins, GitHub Actions) — сборка падает при нарушении правил;
обучения новых разработчиков принятым в проекте стандартам;
снижения технического долга за счёт раннего выявления проблем форматирования и структуры.
Пример: Пример:
Конфигурация Checkstyle (checkstyle.xml):
xml
<module name="MethodLength">
<property name="max" value="100"/>
</module>
<module name="LineLength">
<property name="max" value="120"/>
</module>
Источник: https://checkstyle.sourceforge.io/
RU / EN: Отладка / Debug (Debugging)
Определение: Процесс поиска, анализа и исправления ошибок (багов) в программном обеспечении. Отладка включает выявление проблемы, локализацию её источника в коде, внесение исправлений и проверку работоспособности программы после изменений.
Контекст использования: Отладку применяют:
на этапе разработки — для устранения синтаксических и логических ошибок;
при тестировании — для локализации причин сбоев и некорректного поведения;
в процессе эксплуатации — для анализа ошибок, выявленных пользователями;
для оптимизации производительности — выявления узких мест и утечек памяти;
при интеграции компонентов — для устранения проблем взаимодействия модулей;
в обучении программированию — для понимания работы алгоритмов и механизмов выполнения кода.
**Пример:**Пример отладки в IDE (IntelliJ IDEA):
Установите точку останова на строке с подозрением на ошибку (клик слева от номера строки).
Запустите программу в режиме отладки (Shift+F9).
При остановке на breakpoint:
просмотрите значения переменных в панели Variables;
выполните код пошагово (F8 — step over, F7 — step into);
вычислите выражения в окне Evaluate Expression (Alt+F8).
Внесите исправление в код.
Перезапустите отладку для проверки.
Задача: Не могу понять разницу между JDK, JRE и JVM — когда какой нужен?
Контекст: Изучил определения в Oracle Docs, но практическое применение не ясно. У меня установлен JDK 25, в build.gradle нет упоминания JRE.
Ограничения: Пробовал поискать на Stack Overflow, но там смешаны примеры для Java 8 и Java 25.
Ожидаемый результат: Чёткое понимание, когда мне нужен JDK (для компиляции), когда JRE (для запуска), и что делает JVM (исполнение байт-кода).
Критерии успеха: Могу объяснить коллеге разницу и показать пример: JDK для javac, JRE для java, JVM внутри обоих.
Задача: Чем файлы в стадии коммита отличаются от тех, что в стадии индекса.
Контекст: Изучил сайт Stack Overflow по этому запросу.
Ограничения: Стала понятна разница в определениях между индексом и стадией коммита, но так и не стало понятно, почему изначально нельзя было сделать так, чтобы файлы попадали в коммит после первой же команды.
Ожидаемый результат: Хочу понимать, зачем нужна стадия staging area, если можно было бы сразу коммитить изменения одной командой.
Критерии успеха: Смогу подробно объяснить для чего нужна стадия staging area и буду более умело пользоваться гитом как инструментом.