Перед тем как отправить своё решение на проверку преподавателю, сверьтесь с чеклистом.
1. В решении выполнены все требования задания
Убедитесь, что все требования задания выполнены. Для этого перед отправкой внимательно прочтите весь текст условия задания и соотнесите сказанное в нём с вашим решением. Навык самопроверки работы перед ревью пригодится вам как при обучении, так и на работе.
2. Правильно настроен Maven-проект, тесты проходят
Репозиторий должен быть папкой вашего Мавен-проекта. Обратите внимание, что репозиторием не должна быть папка, в которой лежит папка Мавен-проекта, он сам должен быть папкой проекта. В нём должны быть соответствующие файлы и папки — pom.xml
, src
и другие.
Не забудьте создать .gitignore-файл в корне проекта и добавить туда в игнорирование автогенерируемую папку target
.
Общая схема вашего pom.xml
-файла:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>ru.netology</groupId>
<artifactId>НАЗВАНИЕ-ВАШЕГО-ПРОЕКТА-БЕЗ-ПРОБЕЛОВ</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
...
</dependency>
...
</dependencies>
<build>
<plugins>
<plugin>
...
</plugin>
<plugin>
...
<executions>
<execution>
...
</execution>
...
</executions>
</plugin>
...
</plugins>
</build>
</project>
Обратите внимание, что у артефакта нет -api
на конце. Если у вас автоматически добавилась зависимость вида <artifactId>junit-jupiter-api</artifactId>
, то лучше поменять артефакт на тот, что ниже, иначе будут сюрпризы в работе.
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.7.0</version>
<scope>test</scope>
</dependency>
Без этого плагина тесты могут Мавеном не запускаться, хоть в идее через кнопки они и будут проходить. Чтобы лишний раз убедиться, что всё работает, нажмите Ctrl+Ctrl
и затем mvn clean test
.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<failIfNoTests>true</failIfNoTests>
</configuration>
</plugin>
3. Что делать, если возникли сложности
Это здорово. Если их преодолевать правильно, то можно получить большую образовательную пользу для себя. Периодическое возникновение вопросов, недопонимание пройденного материала — нормальная и неотъемлемая часть обучения. А мы здесь, чтобы помочь вам пройти этот путь.
- Если подобный вопрос разбирался на лекции, посмотрите ещё раз раздел с этой темой в видеозаписи.
- Если вопрос не решился, попробуйте поискать ответ самостоятельно в интернете, этот навык пригодится вам в работе.
- Если самостоятельно разобраться не удалось, задайте вопрос в общем чате, мы обязательно поможем.
- Прежде чем задать вопрос по условию задачи, перечитайте его ещё раз и убедитесь, что в тексте условия нет прямого ответа на этот вопрос. Умение работать с текстом — важный навык работы с информацией.
- Если ответа на свой вопрос в тексте условия не увидели, задайте его в общем чате, мы раскроем детали условия.
Если ваша проблема — это ошибка компиляции — подчёркивает красным, не даёт запустить программу, сборки проекта, CI и прочие подобные ошибки, то:
- Найдите и прочитайте текст ошибки, который вам подсвечивает идея или логи. «Подчёркивает красным» — это не описание ошибки.
- Попробуйте понять текст ошибки, при необходимости воспользуйтесь переводчиком. Не страшно, если вы переведёте неточно, тут главное — сам процесс: со временем и с нашей помощью вы будете это делать лучше и лучше, но, пропуская этот этап, вы не сможете научиться это делать.
- Если не получилось понять ошибку по её тексту, попробуйте её загуглить и изучить подобную ошибку у других людей. Попробуйте примерить решения их проблем на свой код. Соотнесите найденные описания ошибки с пройденной теорией.
- Если всё равно ваши трудности не разрешились, напишите в общий чат, обязательно указав:
- название задачи и ссылку на условие;
- ссылку на вашу работу;
- текст и скриншот, не фотографию, ошибки;
- ваши размышления и описание шагов, которые вы совершили для решения.
Если ваша проблема — это ошибка исполнения, программа умирает уже после запуска, или она отрабатывает неправильно, из-за чего ваши тесты не проходят, то:
- Воспользуйтесь отладчиком для пошагового анализа работы вашей программы. Так вы или убедитесь в неправильности придуманного вами алгоритма, или найдёте конкретное место, где ожидаемое поведение программы разошлось с фактическим.
- Если проблему найти не получилось, напишите в общий чат, обязательно указав:
- название задачи и ссылку на условие;
- ссылку на вашу работу;
- конкретное и подробное описание проблемы или затруднения при решении задачи. «Помогите, что-то не так» — это не описание;
- подробное описание вашего анализа программы с помощью отладчика вместе со скринами;
- ваши размышления и описание шагов, которые вы совершили для решения.
4. Отформатирован код
Кроме правил, нарушение которых приводит к ошибкам компиляции, есть ещё и правила форматирования кода, соблюдение которых обязательно при написании программ.
С большинством проблем может справиться автоформатирование в идее. Для этого выберите Code -> Reformat code
в меню или используйте горячие сочетания клавиш. В меню будет показано актуальное сочетание для вашей операционной системы. Так, идея поправит неправильные отступы, пробелы и некоторые другие ошибки. Следите, чтобы у if-else
, for
, while
всегда были {}
.
Проблемы с именованием сущностей нужно решать самим. Так, все ячейки, кроме final
-констант, и методы должны писаться камелкейсом с маленькой буквы, а классы и интерфейсы — камелкейсом с большой буквы.
Мы вам настоятельно советуем всегда держать код в отформатированном виде во время разработки, со временем глаз привыкнет, и вы почувствуете, насколько это облегчает поиск ошибок в коде и его анализ. В любом случае перед отправкой кода на проверку его обязательно нужно отформатировать, иначе он может быть отправлен на доработку без более глубокой проверки на этой итерации.
5. Настроен Github CI с verify-сборкой Maven и JaCoCo в режиме генерации отчётов с покрытием на 100% по бранчам методов с логикой
После связывания локального репозитория с удалённым и первого пуша в заготовки проекта, время настроить CI на основе GitHub Actions. Шаблон вашего maven.yml должен выглядеть вот так, убедитесь, что всё совпадает с вашим шаблоном, например, что вы указали фазу verify
, а не package
:
name: Java CI with Maven
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Build with Maven
run: mvn -B -e verify
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.5</version>
...
Инициализация:
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
В режиме генерации отчётов:
<execution>
<id>report</id>
<phase>verify</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
В режиме проверки и обрушения сборки по уровню покрытия:
<execution>
<id>check</id>
<goals>
<goal>check</goal>
</goals>
<configuration>
<rules>
<rule>
<limits>
<limit>
<counter>LINE</counter>
<value>COVEREDRATIO</value>
<minimum>100%</minimum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
Вы развиваете приложение с менеджером товаров, который мы рассматривали на лекции, и решили сделать так, чтобы при попытке удаления несуществующего объекта из репозитория генерировалось ваше исключение, а не ArrayIndexOfBoundsException
.
Обратите внимание: это правильный подход, поскольку таким образом вы сообщаете через генерацию исключения, что это исключение, вписывающееся в вашу логику, а не ошибка программиста.
Что нужно сделать:
- Возьмите проект с менеджером, репозиторием и товарами, мы его писали в рамках ДЗ про наследование.
- Создайте класс исключения
NotFoundException
, отнаследовавшись отRuntimeException
, и реализуйте как минимум конструктор с параметром-сообщением. Он будет просто вызывать суперконструктор предка, см. подсказку. - В методе удаления
removeById
сначала проверяйте, есть ли элемент. Для этого прямо из методаremoveById
вызывайте методfindById
: если результатnull
, тогда выкидывайте исключениеNotFoundException
. - Напишите два автотеста на репозиторий: первый должен проверять успешность удаления существующего элемента, второй — генерации
NotFoundException
при попытке удаления несуществующего элемента.
Подсказка
Конструктор вашего исключения должен выглядеть как-то так: public NotFoundException(String s) {
super(s);
}
Для реализации этой логики вам понадобится добавить метод findById
, предназначенный для поиска товара в репозитории по его ID. Так, он должен принимать параметр ID
искомого товара, пробегаться по всем товарам репозитория и сверять их ID
с искомым, в случае совпадения делать return
этого товара. Если же, пробежав все товары репозитория, ни один подходящий найден не был, то есть цикл закончился без вызова return
внутри него, то следует сделать return null
. Общая схема этого метода будет такой:
public Product findById(???) {
for (???) {
if (???) {
return product;
}
}
return null;
}
Убедитесь, что ваши автотесты проходят. Напоминаем, что проект должен быть на базе Maven, с подключёнными зависимостями и необходимыми плагинами.
Итого: у вас должен быть репозиторий на GitHub, в котором расположен ваш Java-код и автотесты к нему.
Мы рекомендуем вам указывать в сообщении исключения: при удалении по какому конкретно ID было сгенерировано ваше исключение.
Простейший способ, как это можно сделать: "Element with id: " + id + " not found"
.
Итого: отправьте на проверку ссылку на репозиторий GitHub с вашим проектом.
В том же самом проекте и в той же самой ветке добавьте следующую новую функциональность. В методе добавления нового товара в репозиторий должна осуществляться проверка на то, что в нём уже нет товара, у которого бы совпадал ID
с ID
добавляемого товара. Если же такой есть, то должно выкидываться ваше исключение —
AlreadyExistsException
.
Напишите два автотеста на репозиторий: первый должен проверять успешность добавления элемента, второй — генерации AlreadyExistsException
при попытке добавить элемент с повторяющимся ID
.
При отправке решения в личном кабинете прикрепите ссылку на ваш публичный репозиторий GitHub с проектом.