Доброго времени суток. Я студент курса JavaRush. У меня 100% прохождения курса по PREMIUM и 1485 решенных задач.
Я расскажу вам как пройти курс легче. Статья рекомендуется для студентов 20+ уровня. Прошу поставить больше 50 или 100 лайков, чтобы я смог получить свое последнее достижение в JR. Статья большая. Но прошу прочитать все (если еще не закончили курс). Я тот кто прочитал 80% от всех комментариев под лекциями и задачами начиная с 25 уровня, на них опираются мои заявления и наблюдения. Возможны ошибки в статье. Приятного чтения!
1. Квесты
Как многие знают квест Syntax был переписан пару лет назад. Это самая лучшая часть JR, наиболее теоретически полная, наиболее щадящий валидатор и инструменты с новых версии Java. Начиная с квеста Core вы встретите старые квесты JR. Они неплохие, но с Syntax не сравнить. В них меньше теории, валидатор упрямее и задачи сложнее. Уровни 1-5 Core самые легкие, а после начинается жесть. Уровни 6-10 Core проходились в режиме: 2-5 минут чтение лекций, 5-30 минут на решение задач, 2-4 часов на чтение комментариев, на чтение статей и просмотр уроков из ссылок в комментариях. Этот период наиболее требователен к теории и требует много времени.
Правильная очередность прохождения квестов
В ранние годы курса очередность прохождения была Syntax => Core => Multithreading => Collections. Это также является рекомендуемой очередностью. Сейчас после Core можно проходить любой из 2 квестов. Но проходить Collections сразу после Core лучше не стоит. Некоторым субъективно легче (также интереснее/нужнее) так проходить. Но объективно этот квест сложнее, сложные большие задачи, много больших задач с паттерном MVC который должен был быть пройден в квесте Multithreading. Там мы работаем с многими фреймворками и различными библиотеками, тем самым уже подготавливаясь к работе. В этом квесте к финалу у вас будет штук 20 зависимостей через Maven, которые вы должны были установить.
На самом деле, названия квестов не отражают их действительность (это некоторых разочаровывает). В квесте Java Multithreading уровни 1, 2, 3, 4, 9, 10 это продолжение CORE. Только уровни 5, 6, 7, 8 обучают работам с потоками. Некоторые могут их пропустить, посчитав ненужными, но я советую их пройти, так как уровни 5, 6, 7 это базовая база, и только уровень 8 отличается сложностью и углублением.
В квесте Collections только 6, 7 уровни про Collections, остальное же фреймворки, паттерны и всякая всячина.
Квесты "JSP & Servlets" и "SQL & Hibernate" самые свежие и не изученные. В них нет задач, есть только теория. Как ознакомление с темами, или как справочник, они не плохи (не даю гарантии). Их лучше проходить после (параллельно) основных квестов. Квест "SQL & Hibernate" полностью посвящен работам с базами данных. А квест "JSP & Servlets" посвящен разным темам, таких как: сборщики проекта Mavan, тестирование JUnit 5 или Mockito, логирование, языки для фронтенда, устройство Web, методология разработки, работа с памятью, библиотеки Concurrency и Apache Commons.
2. Большие задачи
1) Большие задачи Multithreading. Большие задачи (дальше БЗ) часто не связаны по смыслу с уровнями и квестами (это некоторых разочаровывает). Они не завершают уровень и не закрепляют, они сами по себе. В 4 уровне Multithreading есть БЗ "MVC", к нему есть одна небольшая лекция в Collections "6 уровень, 1 лекция" и 2 задачи чуть дальше "6 уровень, 4 лекция". Если сначала пройти их вам может стать легче и понятнее (лекций можно читать в инкогнито, ЧМ фармить в опросах). В 6 уровне Multithreading есть БЗ "Многопользовательский Чат", там есть немного работы с потоками а также с сокетами. Про них подробнее есть в квесте Java Collections "10 уровень, 7 лекция", но не стоит откладывать задачу чтобы сначала дойти до этой лекции. В 7 уровне Multithreading есть БЗ "Archiver", его советуется проходить после прохождения 1 lvl квеста Java Collections. В БЗ-8 lvl "HTML редактор" можно набрать опыт работы с Swing. В 9 уровне есть БЗ "Ресторан" и он многими нарекается как самая сложная БЗ. Может из-за того что я проходил его последним, мне было легче. Единственное там есть 10-ая задача (и связанная с ним 17) в котором нужно реализовать жадный алгоритм. Проверка валидатором там специфичная и не принимает множество решений. По предположению "Павла", "безумного ученого" (ТОП-1 по рейтингу), в правильном решений алгоритм собирает рекламы в определённом порядке. И решение должно работать так же, чтобы приниматься валидатором. Это одна из немногочисленных задач с неправильными, недоработанными тестами валидатора в моей памяти. Лично я решил скопировать правильное решение для задачи 10 и вставить свое решение в 11. Мое решение без проблем прошло 17 задачу, но если вы честно решили задачу 10 оно может провалиться в 17-задаче.
2) Большие задачи Collections. Есть БЗ "Агрегатор" в 8 уровне и многие жалуются на устаревание этой задачи. Сама задача пишется для сохраненных в кэше страниц (старые версий сайтов). Но задачу можно актуализировать на реальные сайты за 30 минут, если хорошо понять 9 и 16 задачи. Многих путает то что валидатор хочет видеть адреса реальных сайтов (но теги там уже другие), но по факту мы пишем код для страницы в кэше. Для большего понимания советую до этой задачи попрактиковать пару часов HTML-CSS.
3) Большие задачи Games. Это большие задачи которые я рекомендую пройти первыми. Они самые доработанные, легкие, с подробным ТЗ, а также не консольные (как в квестах) и имеют красивые GUI. Предполагаю что они создавались вместе с новым квестом Java Syntax. Решая эти игры можно набить руку в больших задачах, и не гореть когда создаете некрасивые версии этих же игр в главных квестах. Если вы решите эти игры то потом можно не проходить большие задачи в 1, 2, 3 уровнях Multithreading и 2, 3 уровнях Collections. В 10 уровне квестов Multithreading, Collections тоже расположены игры, но они оба годные и являются примерами хороших задач.
3. Лекций и Задачи
Существуют такие люди, которых для хорошей мотивации стоит постоянно держать в напряжений. Они не любят когда все легко и им становятся скучно. Возможно для этой части студентов существуют "сложные" задачи (которые многим не нравятся, даже тем для кого они созданы). Их сложность состоит не только в сложности самой задачи. Обычно они помечаются различными знаками по типу домика (домашние задания) или звезды (бонусные задания). Если я правильно понимаю, то домиком помечаются задания, для которых требуется самостоятельная работа и поиск теоретических материалов. Задачи со звездочкой - это обычно бонусные задачи на алгоритмы, или темы, не относящиеся к основным уровням, а так же задачи с собеседовании. Лично я не придавал такому разделению особого значения до этого дня, и вам тоже советую не смотреть на значки и цвет задач. Но есть два типа "сложных" задач, на которые стоит обратить внимание, это "задачи из будущего" (скорее всего будут помечены домиком) и "задачи без будущего" (скорее всего будут помечены звездой или домиком). Особенность "задач из будущего" в том, что для их решения у вас нет знании из пройденных лекции, и эти знания появятся в среднем через 4-5 лекций, а максимум через 2-3 уровня после. Если вы решите их отложить и вернетесь через некоторое время, задача падет под силой ваших знании. Вы из "будущего" легко их решите. Особенность "задач без будущего" в том, что даже прочитав все лекций и решив все задачи, вы, вернувшись к этим задачам, не сможете их решить. Для этих задач нет теории в JR. Либо вы решите задачу сейчас или не решите никогда. Методы решения таких задач обычно находятся под самой задачей в комментариях, или же в просторах интернета. Чаще всего это задачи на алгоритмы, и реже обычные, но сложные задачи. В топе самых сложных задач стоят именно такие задачи.
3.1. Как проходить лекций?
Учитывая выше сказанное, я предлагаю вам открытой мной случайно и созданный другими проверенный метод, который сберег им много нервов и времени. Оно заключается в том, чтобы читать лекции на 2 или максимум на 5 уровней вперед, и только потом возвращаться назад и решать задачи, которые вы оставили. Поверьте этот метод будет очень полезным. Лично я не помню, чтобы теория к задаче давалась через 5 уровней. Помню, что были примеры на 2 уровня, и только мелкие темы, которые давались в общем виде в прошлом, разбираются подробно только много уровней спустя.
3.2. Как решать задачи и не воевать с валидатором?
Если вы примените метод прохождения лекции, описанный выше, решать задачи станет легче. Но это не решает вопрос с валидатором. Далее я дам пару тактик и методов. Это очень важно поэтому прошу быть внимательными и прислушаться.
1) Общие тактики
Как не воевать с валидатором? Не воевать с ним. Как только вы отправите задачу на проверку, вы начнете с ним войну. Но что будет, если не отправлять задачу на проверку? Правильно, не будет войны. Звучит безумно но послушайте до конца. Эта тактика была придумана мной чтобы получить платиновый мегатрон. Я решал задачу => сам проверял => удалял слово class из имени класса => отправлял на проверку (чтобы оно сохранялось в разделе "В прогрессе") => продолжал так пока их не соберется около 100-ни => разом отправлял на проверку около 20 задач => 10-15 сразу решались правильно. Те задачи, которые не прошли валидацию, я смотрел заново, пытался вспомнить о чем задача, перечитывал лекции, охреневал от того, что написал такую глупость или допускал ошибку, переписывал, дорабатывал, подсматривал в правильные решения и оставлял задачу, чтобы не сильно читерить, и возвращался, когда уже забыл, что там было. Такой метод прохождения сохранит вам много нервов. Мы сами выбираем удобное место и время сражения. Если нам навязывают бой, мы отступаем и пересматриваем свою тактику. Если проиграли, вызываем подмогу. Это способ войны с малыми жертвами.
Как не воевать с валидатором? Подружиться с его врагом. Кто враг валидатора, который всегда его побеждает? Ответ: правильное решение. Да, определенно, это очень тернистый путь и коварный союзник. Если вы не будете думать своей головой и всегда будете полагаться на него, то вы определенно проиграли. Кто должен быть победителем вы или он? Если вы привыкнете сдаваться из-за небольшого давления, это не закончится ничем хорошим. Этот способ - это крайний метод. Его стоит использовать только с "упрямыми задачами", или чтобы определить тип задачи. Некоторые люди брезгуют таким методом и испытывают определенные комплексы, когда дело касается такой деликатной темы (но если подумать то подсказки в комментариях это тоже читы). Но я могу дать вам "техники безопасности", которые могут сгладить углы. С ними вы сможете наследовать лозунг: "читать правильное решение тоже часть обучения". Даже если сами решили задачу, то после все равно посмотрите в "правильные решения". Это полезно, когда вы ошиблись в своем коде, но валидатор его все равно принял, когда решение отличается от вашего или когда "правильное решение" гениальное и простое. К тому же у вас развиться чуйка на желания валидатора: "скорее всего он это не примет", "кажется я знаю что он хочет", "попробую-ка это, валидатор скорее всего не примет, но я все равно попробую", "это он не должен был принимать, но принял, странно, подсмотрю в правильные решения".
"Техника безопасности"
1) Если подсмотрели в правильное решение, не решайте задачу сразу. Вернитесь через месяц когда уже забыли все детали.
2) Если при изучений правильного решения вы поняли что в своем решении вы всего лишь не учли "безликие" тесты, то смело завершайте задачу. Ну забыли проверить на null, и что? Главное вы знаете то, что в реальном проекте такие проверки это обычное дело и должны быть всегда. А в задачах то они есть, то их нет.
3) Если подсмотрели в правильное решение и поняли что в вашем коде вы упустили какую то важную логику, и до этой логики вы бы додумались сами, то сбрасывайте задачу и выполняйте 1 пункт.
4) Если подсмотрели в правильное решение и поняли... что ничего не поняли и то что решение слишком замудренное для вас, то ваши чувства вас не обманули. В JR не редки такие задачи. Для почти всех из них существуют простые и элементарные решения. Это вы можете подтвердить посмотрев в комментарии. Такие задачи безопасны и даже полезны. Например задача task3404 или task2025.
5) Некоторые правильные решения не работают или имеют ошибки, иногда простые иногда грубые. Но в таких задачах вы сами сможете написать корректное решение. Даю гарантию. Такие задачи вредят вам, если вы в них поверили, но если вы заметили ошибку то это только пойдет вам на пользу.
6) Некоторые упрямые задачи все же требуют более детальное наблюдение и анализ упрямых частей. В таких задачах советую обратить внимание на комментарии. "Правильные решения" таких задач безопасны. Какая разница что задача решалась через способ "е", а не "ё"? Вы не должны тратить на такие нюансы свои дни.
7) Если решили скопировать "правильное решение" то не делайте это через Ctrl + C и Ctrl + V. Подсмотрите в "правильное решение", разберите и закройте его. Пишите на чистом листе IDEA ручками, на память, как будто вы никуда не смотрели и пишете то что у вас всегда было на уме. Это помогает мозгу усвоить задачу не давая ему обойтись нажатием пары кнопок.
8) Если вы не дуб, задача которую вы решаете не из "топа сложных задач" и вы тратите на нее уже больше 3 дней, то вы делаете что-то не так. "Правильное решение" для вас безопасна.
Как не воевать с валидатором? "Папич и Portal 2" или "А ты знаешь, что такое безумие?"
В психологии существуют такое когнитивное искажение как "ошибка невозвратных затрат". Вы вкладываете много сил в какой нибудь код или метод. Даже если этот код не работает должным образом, слишком замудрен, слишком сложен или работает грубой силой вы продолжаете его дописывать, так как уже вложили слишком много сил. В таких ситуациях, когда задача ну никак не поддается решению, нужно задумываться: "А может все стереть и сделать по новой?". Перелопачивание кода не редко приводит к тому что валидатор все же принимает код, но вы должны помнить что к этому нет никакой гарантии. Новый код может также не приниматься валидатором. Или старый код был ближе к правильному, и нужно было лишь немного его подправить. Но обычно ваша чуйка, если она хороша, сама вам все подскажет. Но если вы не доверяете своей чуйке, то прочтите комментарии или подсмотрите в "правильное решение", затем отложите задачу и решите через месяц.
Как не воевать с валидатором? Станьте валидатором
Этот пункт самый важный. Больше половины всех вопросов в разделе "помощь" решается простыми проверками правильности написания кода, исправлениями орфографических ошибок или вообще простым запуском. Такая практика делает вас более компетентным и приближает к реальной работе, возможно вы станете QA? Напишите в "main" простые тесты.
Например, методы div2 или div3 из примера внизу. Дайте переменным значения x = 3, y = 2 и вы увидите что они работают по разному. Как бы вы поняли это, не написав тесты и не запустив код?
Если задача упряма возьмите "правильное решение" и ваш код, напишите сравнивающие Unit тесты, и, возможно, вы полюбите валидатор)))
2) Частные тактики
Когда вы решаете задачи и отправляете на проверку, задача, в зависимости от требовании, проходит различные тесты. Тесты самые разные, я могу поделить их на "безликие" и "цветные".
"Безликие" тесты
public static void main(String[] args) {
System.out.println(div(null, 2));
System.out.println(div(3, 0));
System.out.println(div(3, 2));
System.out.println(div(4, 2));
}
public static int div(Integer x, Integer y) {
return x/y;
}
1) Проверка когда в параметрах дается null;
2) Проверка граничных значений. Например, что делает метод div когда y = 0?
3) Проверка на правильность возвращаемых значений. Например, когда в метод div предать x = 3, y = 2 он должен вернуть число 1 а не 1.5 или 1.0. Какой метод вернет какой результат?
public static int div(Integer x, Integer y) { //div1
return x / y;
}
public static double div(Integer x, Integer y) { //div2
return x / y;
}
public static double div(Integer x, Integer y) { //div3
return x * 1.0 / y;
}
Такие тесты я называю "безликими". Они не зависят от решаемой задачи и "по хорошему" должны быть везде. Но, к сожалению, они не встречаются во всех задачах. Иногда они есть, но часто их нет. Это и есть самая большая проблема. Ты не знаешь есть ли эти тесты при валидации и решаешь задачу не учитывая их. И только пройдя их задача пройдет валидацию.
"Цветные" тесты
Иногда существуют "цветные" тесты, которые проверяют решалась ли задача каким то определенным образом. Например, оно может проверить использовал ли ты метод doSomething или нет. Они обычно оговариваются в условиях задачи и созданы чтобы мы не мухлевали, ищя обходные пути. Говорят что есть задачи где такие тесты есть, но они не указаны в условиях. 50% таких задач я или комментаторы точно проверили и опровергли (я читал комментарии и пытался решать по другому), 5-10% таких задач подтверждались (я не находил другие способы), а остальные 40-50% просто прошли мимо меня.
Существуют упрямые задачи такие как Ресторан(10) (самый упрямый на моей памяти). Ваш код дает тот же результат, что и код из правильного решения, но все равно не нравится валидатору. Обычно эти задачи "цветные", но их скрытые проверки неочевидны, странны и не изучены. Так как такие задачи не изучены, я лишь могу дать несколько гарантии.
Гарантии
1) Нет задач где важно как ты назвал поле или метод (если этого нет в условиях)
2) Нет нерешаемых задач
3) Нет невозвратно устаревших задач. Все задачи можно допилить и актуализировать. Например: задача task4003 или БЗ "Агрегатор"
4) Нет абсолютно некорректных задач. Есть задачи где "правильные решения" имеют ошибки или которые даже не компилируются. Но саму задачу можно корректно решить своими силами
5) Нет задач которые не принимают "правильное решение"
6) Все упрямые задачи уже решены другими и они могут подсказать вам что делать в комментариях
7) Есть задачи где вы никогда не поймете "правильное решение", но все эти задачи можно решить относительно простыми и элегантными решениями. Например: task3404 или task2025 (оба из топа самых сложных задач)
3.3. Топ самых сложных задач
Во время когда вы все еще проходите курс, почти все задачи на новые темы, тип задач которые вы решаете впервые или задачи на всякие нюансы Java будут для вас сложными. Но если смотреть с высоты 51 уровня, то реально сложных и долгих задач будет не больше 10 штук. На них, в отличие от других задач, можно без проблем тратить свои дни. Итак, знайте своих врагов на лицо.
4. Комментарии
Нужно ли мне что либо говорить? Комментарии это сокровище JR. Но большинство комментариев, на счет багов и недочетов, до 2020 года устарели, так как были исправлены. Могу только порекомендовать читать хотя бы 5-10 комментариев из "популярных" и "новых".
5. Лайфхаки, нюансы, достижения, интересные факты, предупреждения и разное
1) Все лекции будут открыты для вас в режиме инкогнито;
2) Опросы можно перепроходить бесконечно и зарабатывать "Черную материю". Они находятся в квесте "Java Syntax PRO";
3) В квестах "JSP & Servlets" и "SQL & Hibernate" нет и не будет задач. Они только студентам "JavaRush университета";
4) Через 5 миллиардов лет солнечная система будет уничтожена;
5) Большинство достижений имеют градацию 7 раз => 21 раз => 42 раз. Есть достижение "100 дней кода" когда вы должны решать по задаче 100 дней подряд;
6) Сбрасывая "Большую задачу" вы сбрасываете ее в самое начало;
7) Решая "Большую задачу", при переходе на следующий уровень, ваш написанный код может быть подменен решением из JR. Это нужно, чтобы последующий код не падал в ошибках, из-за неправильности предыдущих уровней. Но это мало кому нравится. Поэтому советую сохранять свою версию решения каждый уровень;
8) Квест "Spring" очень нечитабельный. Поговаривают что там просто перевели официальную документацию;
9) В некоторых местах есть скрытые страницы. Возможно старые квесты или лекции из "университета";
10) Существует способ быстрой навигации. Особенно полезны в БЗ. Простая задача: https://javarush.com/tasks/com.javarush.task.task22.task2211#discussion и большая задача https://javarush.com/tasks/com.javarush.task.task36.task3608.big05#discussion;
11) Некоторые большие задачи, на создание игр, имеют старые версии в квестах Multithreading и Collections и новые версии в разделе Games. Не решая их вы сэкономите себе время.
12) Статистика о прошедших курс
13) Курс JR не достаточен для вас если вы хотите устроится на работу. В курсе нет многих тем, технологии, и фреймворков. Но оно и не нужно, ведь нет ничего лучше чем крепкая основа. С остальным вы разберетесь легко и быстро.
6. Обо мне. Время прохождения курса на 100%
Я изначально учился по специальности "Радиотехника, электроника и телекоммуникации" в Алмате, затем отработал год "сетевым инженером". Сейчас почти год работаю как "SQL Developer" (скорее как data engineer). Занимались миграцией данных и разрабатывали ETL процессы. До этого в универе 1 семестр проходил Python на уровне c = a + b. Дальше проходил курсы в Stepik о Kotlin (хотел в моб разработку) на уровне прохода циклов for.
Затем перешел в Java и купил курс 5 августа 2022. Курс сразу не осилил, поэтому сперва прошел за месяц небольшой курс в Stepik о Java. Работал полный рабочий день, занимался в свободное время. Посвящал учебе хотя бы часа 2, на выходных целый день. Было время когда 4 месяца жил в режиме дом-работа. После этого простая поездка по городу казалась поездкой в Турцию. На 100% прохождения одного квеста уходило примерно 4 месяца. Syntax был пройден за 2 месяца, Игры тоже 2 месяца. Core, Multithreading, Collections проходил 4 месяцев каждый. Были выходные и пропуски на месяц, поэтому у меня ушло 1 год и 11 месяцев. Если не будете рефлексировать, и читать каждый комментарии, можете пройти курс (без опыта, с нуля) на 100% за 16 месяцев, параллельно работая 8 часов в день. Если вы не работаете, то курс вполне себе можно пройти за год или меньше.
7. Что дальше
При прохождении курса я не смотрел ни на лево, ни на право. Вам я такое не советую. Уже ближе к концу Collection нужно понемногу начать осваивать вещи что не будут в курсе. Хотя, если вы не торопитесь, учите все постепенно, также как и я. Мой дальнейший путь скорее всего будет по этой ROADMAP. Думаю оно будет полезнее вам, чем 1000 лишних слов.
Спасибо что прочитали!
Здравствуйте. Подскажите как учились.
- сколько в день тратили время на учебу/теорию, решение задач
- в выходные учились/нет
- и вообщем сколько дней заняло до достижения 38-40 уровня
Если не сложно - отпишитесь. Хорошего дня)
Отличная статья. Как-то опустила меня на землю. Только закончил Syntax - за год (работа, семья, перерывы в общей сложности 6 месяцев) и почему-то решил, что самое сложное позади и дальше все пойдет как эти первые лекции, которые делаю сейчас на Core. Но статья приземлила. Судя по всему думать о собеседованиях не совсем скоро придется, если даже на 50-ом уровне знаний для работы не будет хватать.
Хорошая статья. От себя добавлю свои пару копеек. Для начала, прохожу javarush второй раз... Первый раз когда проходил(несколько лет назад) не выполнил только 2-3 задачи из курса. ~85 - 88% - c первого раза. Затраченное время 5 месяцев (работал, но семьи еще не было). Дальше Кислин... После него, через два месяца - получение офера.
Так вот - банальный лайфхак для прохождение задач с первого раза.
1. Читаете описание и осмысливаете чё от вас хотят. Если не поняли, что от вас хотят - переходите к пункту 2.
2. Самый главный пункт по решению задач. Выполнить все условия которые стоят в пункте ТРЕБОВАНИЯ... Перед сдачей задачи, пройтись по каждому пункту и посмотреть выполнен ли они. Ну, а если в требованиях к задаче указывается, что нужно выполнить условия поставленные в описании(такое бывает) - идем читать комментарии. Заметил такую тендецию - чем старее комментарии - тем они более грамотные..
Почему прохожу второй раз? Уже долго не работаю, так Я подготавливаюсь к собеседованию...
Спасибо за статью!
Автор, поделись опытом программирования, пришел ли сюда с нуля?
Как давно начал, сколько уделял времени и на каком этапе в данный момент? Какие перспективы?
За развернутый ответ 👍
Я расскажу вам как пройти курс легче. Статья рекомендуется для студентов 20+ уровня. Прошу поставить больше 50 или 100 лайков, чтобы я смог получить свое последнее достижение в JR. Статья большая. Но прошу прочитать все (если еще не закончили курс). Я тот кто прочитал 80% от всех комментариев под лекциями и задачами начиная с 25 уровня, на них опираются мои заявления и наблюдения. Возможны ошибки в статье. Приятного чтения!
1. Квесты
Как многие знают квест Syntax был переписан пару лет назад. Это самая лучшая часть JR, наиболее теоретически полная, наиболее щадящий валидатор и инструменты с новых версии Java. Начиная с квеста Core вы встретите старые квесты JR. Они неплохие, но с Syntax не сравнить. В них меньше теории, валидатор упрямее и задачи сложнее. Уровни 1-5 Core самые легкие, а после начинается жесть. Уровни 6-10 Core проходились в режиме: 2-5 минут чтение лекций, 5-30 минут на решение задач, 2-4 часов на чтение комментариев, на чтение статей и просмотр уроков из ссылок в комментариях. Этот период наиболее требователен к теории и требует много времени.
Правильная очередность прохождения квестов
В ранние годы курса очередность прохождения была Syntax => Core => Multithreading => Collections. Это также является рекомендуемой очередностью. Сейчас после Core можно проходить любой из 2 квестов. Но проходить Collections сразу после Core лучше не стоит. Некоторым субъективно легче (также интереснее/нужнее) так проходить. Но объективно этот квест сложнее, сложные большие задачи, много больших задач с паттерном MVC который должен был быть пройден в квесте Multithreading. Там мы работаем с многими фреймворками и различными библиотеками, тем самым уже подготавливаясь к работе. В этом квесте к финалу у вас будет штук 20 зависимостей через Maven, которые вы должны были установить.
На самом деле, названия квестов не отражают их действительность (это некоторых разочаровывает). В квесте Java Multithreading уровни 1, 2, 3, 4, 9, 10 это продолжение CORE. Только уровни 5, 6, 7, 8 обучают работам с потоками. Некоторые могут их пропустить, посчитав ненужными, но я советую их пройти, так как уровни 5, 6, 7 это базовая база, и только уровень 8 отличается сложностью и углублением.
В квесте Collections только 6, 7 уровни про Collections, остальное же фреймворки, паттерны и всякая всячина.
Квесты "JSP & Servlets" и "SQL & Hibernate" самые свежие и не изученные. В них нет задач, есть только теория. Как ознакомление с темами, или как справочник, они не плохи (не даю гарантии). Их лучше проходить после (параллельно) основных квестов. Квест "SQL & Hibernate" полностью посвящен работам с базами данных. А квест "JSP & Servlets" посвящен разным темам, таких как: сборщики проекта Mavan, тестирование JUnit 5 или Mockito, логирование, языки для фронтенда, устройство Web, методология разработки, работа с памятью, библиотеки Concurrency и Apache Commons.
2. Большие задачи
1) Большие задачи Multithreading. Большие задачи (дальше БЗ) часто не связаны по смыслу с уровнями и квестами (это некоторых разочаровывает). Они не завершают уровень и не закрепляют, они сами по себе. В 4 уровне Multithreading есть БЗ "MVC", к нему есть одна небольшая лекция в Collections "6 уровень, 1 лекция" и 2 задачи чуть дальше "6 уровень, 4 лекция". Если сначала пройти их вам может стать легче и понятнее (лекций можно читать в инкогнито, ЧМ фармить в опросах). В 6 уровне Multithreading есть БЗ "Многопользовательский Чат", там есть немного работы с потоками а также с сокетами. Про них подробнее есть в квесте Java Collections "10 уровень, 7 лекция", но не стоит откладывать задачу чтобы сначала дойти до этой лекции. В 7 уровне Multithreading есть БЗ "Archiver", его советуется проходить после прохождения 1 lvl квеста Java Collections. В БЗ-8 lvl "HTML редактор" можно набрать опыт работы с Swing. В 9 уровне есть БЗ "Ресторан" и он многими нарекается как самая сложная БЗ. Может из-за того что я проходил его последним, мне было легче. Единственное там есть 10-ая задача (и связанная с ним 17) в котором нужно реализовать жадный алгоритм. Проверка валидатором там специфичная и не принимает множество решений. По предположению "Павла", "безумного ученого" (ТОП-1 по рейтингу), в правильном решений алгоритм собирает рекламы в определённом порядке. И решение должно работать так же, чтобы приниматься валидатором. Это одна из немногочисленных задач с неправильными, недоработанными тестами валидатора в моей памяти. Лично я решил скопировать правильное решение для задачи 10 и вставить свое решение в 11. Мое решение без проблем прошло 17 задачу, но если вы честно решили задачу 10 оно может провалиться в 17-задаче.
2) Большие задачи Collections. Есть БЗ "Агрегатор" в 8 уровне и многие жалуются на устаревание этой задачи. Сама задача пишется для сохраненных в кэше страниц (старые версий сайтов). Но задачу можно актуализировать на реальные сайты за 30 минут, если хорошо понять 9 и 16 задачи. Многих путает то что валидатор хочет видеть адреса реальных сайтов (но теги там уже другие), но по факту мы пишем код для страницы в кэше. Для большего понимания советую до этой задачи попрактиковать пару часов HTML-CSS.
3) Большие задачи Games. Это большие задачи которые я рекомендую пройти первыми. Они самые доработанные, легкие, с подробным ТЗ, а также не консольные (как в квестах) и имеют красивые GUI. Предполагаю что они создавались вместе с новым квестом Java Syntax. Решая эти игры можно набить руку в больших задачах, и не гореть когда создаете некрасивые версии этих же игр в главных квестах. Если вы решите эти игры то потом можно не проходить большие задачи в 1, 2, 3 уровнях Multithreading и 2, 3 уровнях Collections. В 10 уровне квестов Multithreading, Collections тоже расположены игры, но они оба годные и являются примерами хороших задач.
3. Лекций и Задачи
Существуют такие люди, которых для хорошей мотивации стоит постоянно держать в напряжений. Они не любят когда все легко и им становятся скучно. Возможно для этой части студентов существуют "сложные" задачи (которые многим не нравятся, даже тем для кого они созданы). Их сложность состоит не только в сложности самой задачи. Обычно они помечаются различными знаками по типу домика (домашние задания) или звезды (бонусные задания). Если я правильно понимаю, то домиком помечаются задания, для которых требуется самостоятельная работа и поиск теоретических материалов. Задачи со звездочкой - это обычно бонусные задачи на алгоритмы, или темы, не относящиеся к основным уровням, а так же задачи с собеседовании. Лично я не придавал такому разделению особого значения до этого дня, и вам тоже советую не смотреть на значки и цвет задач. Но есть два типа "сложных" задач, на которые стоит обратить внимание, это "задачи из будущего" (скорее всего будут помечены домиком) и "задачи без будущего" (скорее всего будут помечены звездой или домиком). Особенность "задач из будущего" в том, что для их решения у вас нет знании из пройденных лекции, и эти знания появятся в среднем через 4-5 лекций, а максимум через 2-3 уровня после. Если вы решите их отложить и вернетесь через некоторое время, задача падет под силой ваших знании. Вы из "будущего" легко их решите. Особенность "задач без будущего" в том, что даже прочитав все лекций и решив все задачи, вы, вернувшись к этим задачам, не сможете их решить. Для этих задач нет теории в JR. Либо вы решите задачу сейчас или не решите никогда. Методы решения таких задач обычно находятся под самой задачей в комментариях, или же в просторах интернета. Чаще всего это задачи на алгоритмы, и реже обычные, но сложные задачи. В топе самых сложных задач стоят именно такие задачи.
3.1. Как проходить лекций?
Учитывая выше сказанное, я предлагаю вам открытой мной случайно и созданный другими проверенный метод, который сберег им много нервов и времени. Оно заключается в том, чтобы читать лекции на 2 или максимум на 5 уровней вперед, и только потом возвращаться назад и решать задачи, которые вы оставили. Поверьте этот метод будет очень полезным. Лично я не помню, чтобы теория к задаче давалась через 5 уровней. Помню, что были примеры на 2 уровня, и только мелкие темы, которые давались в общем виде в прошлом, разбираются подробно только много уровней спустя.
3.2. Как решать задачи и не воевать с валидатором?
Если вы примените метод прохождения лекции, описанный выше, решать задачи станет легче. Но это не решает вопрос с валидатором. Далее я дам пару тактик и методов. Это очень важно поэтому прошу быть внимательными и прислушаться.
1) Общие тактики
Как не воевать с валидатором? Не воевать с ним. Как только вы отправите задачу на проверку, вы начнете с ним войну. Но что будет, если не отправлять задачу на проверку? Правильно, не будет войны. Звучит безумно но послушайте до конца. Эта тактика была придумана мной чтобы получить платиновый мегатрон. Я решал задачу => сам проверял => удалял слово class из имени класса => отправлял на проверку (чтобы оно сохранялось в разделе "В прогрессе") => продолжал так пока их не соберется около 100-ни => разом отправлял на проверку около 20 задач => 10-15 сразу решались правильно. Те задачи, которые не прошли валидацию, я смотрел заново, пытался вспомнить о чем задача, перечитывал лекции, охреневал от того, что написал такую глупость или допускал ошибку, переписывал, дорабатывал, подсматривал в правильные решения и оставлял задачу, чтобы не сильно читерить, и возвращался, когда уже забыл, что там было. Такой метод прохождения сохранит вам много нервов. Мы сами выбираем удобное место и время сражения. Если нам навязывают бой, мы отступаем и пересматриваем свою тактику. Если проиграли, вызываем подмогу. Это способ войны с малыми жертвами.
Как не воевать с валидатором? Подружиться с его врагом. Кто враг валидатора, который всегда его побеждает? Ответ: правильное решение. Да, определенно, это очень тернистый путь и коварный союзник. Если вы не будете думать своей головой и всегда будете полагаться на него, то вы определенно проиграли. Кто должен быть победителем вы или он? Если вы привыкнете сдаваться из-за небольшого давления, это не закончится ничем хорошим. Этот способ - это крайний метод. Его стоит использовать только с "упрямыми задачами", или чтобы определить тип задачи. Некоторые люди брезгуют таким методом и испытывают определенные комплексы, когда дело касается такой деликатной темы (но если подумать то подсказки в комментариях это тоже читы). Но я могу дать вам "техники безопасности", которые могут сгладить углы. С ними вы сможете наследовать лозунг: "читать правильное решение тоже часть обучения". Даже если сами решили задачу, то после все равно посмотрите в "правильные решения". Это полезно, когда вы ошиблись в своем коде, но валидатор его все равно принял, когда решение отличается от вашего или когда "правильное решение" гениальное и простое. К тому же у вас развиться чуйка на желания валидатора: "скорее всего он это не примет", "кажется я знаю что он хочет", "попробую-ка это, валидатор скорее всего не примет, но я все равно попробую", "это он не должен был принимать, но принял, странно, подсмотрю в правильные решения".
"Техника безопасности"
1) Если подсмотрели в правильное решение, не решайте задачу сразу. Вернитесь через месяц когда уже забыли все детали.
2) Если при изучений правильного решения вы поняли что в своем решении вы всего лишь не учли "безликие" тесты, то смело завершайте задачу. Ну забыли проверить на null, и что? Главное вы знаете то, что в реальном проекте такие проверки это обычное дело и должны быть всегда. А в задачах то они есть, то их нет.
3) Если подсмотрели в правильное решение и поняли что в вашем коде вы упустили какую то важную логику, и до этой логики вы бы додумались сами, то сбрасывайте задачу и выполняйте 1 пункт.
4) Если подсмотрели в правильное решение и поняли... что ничего не поняли и то что решение слишком замудренное для вас, то ваши чувства вас не обманули. В JR не редки такие задачи. Для почти всех из них существуют простые и элементарные решения. Это вы можете подтвердить посмотрев в комментарии. Такие задачи безопасны и даже полезны. Например задача task3404 или task2025.
5) Некоторые правильные решения не работают или имеют ошибки, иногда простые иногда грубые. Но в таких задачах вы сами сможете написать корректное решение. Даю гарантию. Такие задачи вредят вам, если вы в них поверили, но если вы заметили ошибку то это только пойдет вам на пользу.
6) Некоторые упрямые задачи все же требуют более детальное наблюдение и анализ упрямых частей. В таких задачах советую обратить внимание на комментарии. "Правильные решения" таких задач безопасны. Какая разница что задача решалась через способ "е", а не "ё"? Вы не должны тратить на такие нюансы свои дни.
7) Если решили скопировать "правильное решение" то не делайте это через Ctrl + C и Ctrl + V. Подсмотрите в "правильное решение", разберите и закройте его. Пишите на чистом листе IDEA ручками, на память, как будто вы никуда не смотрели и пишете то что у вас всегда было на уме. Это помогает мозгу усвоить задачу не давая ему обойтись нажатием пары кнопок.
8) Если вы не дуб, задача которую вы решаете не из "топа сложных задач" и вы тратите на нее уже больше 3 дней, то вы делаете что-то не так. "Правильное решение" для вас безопасна.
Как не воевать с валидатором? "Папич и Portal 2" или "А ты знаешь, что такое безумие?"
В психологии существуют такое когнитивное искажение как "ошибка невозвратных затрат". Вы вкладываете много сил в какой нибудь код или метод. Даже если этот код не работает должным образом, слишком замудрен, слишком сложен или работает грубой силой вы продолжаете его дописывать, так как уже вложили слишком много сил. В таких ситуациях, когда задача ну никак не поддается решению, нужно задумываться: "А может все стереть и сделать по новой?". Перелопачивание кода не редко приводит к тому что валидатор все же принимает код, но вы должны помнить что к этому нет никакой гарантии. Новый код может также не приниматься валидатором. Или старый код был ближе к правильному, и нужно было лишь немного его подправить. Но обычно ваша чуйка, если она хороша, сама вам все подскажет. Но если вы не доверяете своей чуйке, то прочтите комментарии или подсмотрите в "правильное решение", затем отложите задачу и решите через месяц.
Как не воевать с валидатором? Станьте валидатором
Этот пункт самый важный. Больше половины всех вопросов в разделе "помощь" решается простыми проверками правильности написания кода, исправлениями орфографических ошибок или вообще простым запуском. Такая практика делает вас более компетентным и приближает к реальной работе, возможно вы станете QA? Напишите в "main" простые тесты.
Например, методы div2 или div3 из примера внизу. Дайте переменным значения x = 3, y = 2 и вы увидите что они работают по разному. Как бы вы поняли это, не написав тесты и не запустив код?
Если задача упряма возьмите "правильное решение" и ваш код, напишите сравнивающие Unit тесты, и, возможно, вы полюбите валидатор)))
2) Частные тактики
Когда вы решаете задачи и отправляете на проверку, задача, в зависимости от требовании, проходит различные тесты. Тесты самые разные, я могу поделить их на "безликие" и "цветные".
"Безликие" тесты
4. Комментарии
Нужно ли мне что либо говорить? Комментарии это сокровище JR. Но большинство комментариев, на счет багов и недочетов, до 2020 года устарели, так как были исправлены. Могу только порекомендовать читать хотя бы 5-10 комментариев из "популярных" и "новых".
5. Лайфхаки, нюансы, достижения, интересные факты, предупреждения и разное
1) Все лекции будут открыты для вас в режиме инкогнито;
2) Опросы можно перепроходить бесконечно и зарабатывать "Черную материю". Они находятся в квесте "Java Syntax PRO";
3) В квестах "JSP & Servlets" и "SQL & Hibernate" нет и не будет задач. Они только студентам "JavaRush университета";
4) Через 5 миллиардов лет солнечная система будет уничтожена;
5) Большинство достижений имеют градацию 7 раз => 21 раз => 42 раз. Есть достижение "100 дней кода" когда вы должны решать по задаче 100 дней подряд;
6) Сбрасывая "Большую задачу" вы сбрасываете ее в самое начало;
7) Решая "Большую задачу", при переходе на следующий уровень, ваш написанный код может быть подменен решением из JR. Это нужно, чтобы последующий код не падал в ошибках, из-за неправильности предыдущих уровней. Но это мало кому нравится. Поэтому советую сохранять свою версию решения каждый уровень;
8) Квест "Spring" очень нечитабельный. Поговаривают что там просто перевели официальную документацию;
9) В некоторых местах есть скрытые страницы. Возможно старые квесты или лекции из "университета";
10) Существует способ быстрой навигации. Особенно полезны в БЗ. Простая задача: https://javarush.com/tasks/com.javarush.task.task22.task2211#discussion и большая задача https://javarush.com/tasks/com.javarush.task.task36.task3608.big05#discussion;
11) Некоторые большие задачи, на создание игр, имеют старые версии в квестах Multithreading и Collections и новые версии в разделе Games. Не решая их вы сэкономите себе время.
12) Статистика о прошедших курс
13) Курс JR не достаточен для вас если вы хотите устроится на работу. В курсе нет многих тем, технологии, и фреймворков. Но оно и не нужно, ведь нет ничего лучше чем крепкая основа. С остальным вы разберетесь легко и быстро.
6. Обо мне. Время прохождения курса на 100%
Я изначально учился по специальности "Радиотехника, электроника и телекоммуникации" в Алмате, затем отработал год "сетевым инженером". Сейчас почти год работаю как "SQL Developer" (скорее как data engineer). Занимались миграцией данных и разрабатывали ETL процессы. До этого в универе 1 семестр проходил Python на уровне c = a + b. Дальше проходил курсы в Stepik о Kotlin (хотел в моб разработку) на уровне прохода циклов for.
Затем перешел в Java и купил курс 5 августа 2022. Курс сразу не осилил, поэтому сперва прошел за месяц небольшой курс в Stepik о Java. Работал полный рабочий день, занимался в свободное время. Посвящал учебе хотя бы часа 2, на выходных целый день. Было время когда 4 месяца жил в режиме дом-работа. После этого простая поездка по городу казалась поездкой в Турцию. На 100% прохождения одного квеста уходило примерно 4 месяца. Syntax был пройден за 2 месяца, Игры тоже 2 месяца. Core, Multithreading, Collections проходил 4 месяцев каждый. Были выходные и пропуски на месяц, поэтому у меня ушло 1 год и 11 месяцев. Если не будете рефлексировать, и читать каждый комментарии, можете пройти курс (без опыта, с нуля) на 100% за 16 месяцев, параллельно работая 8 часов в день. Если вы не работаете, то курс вполне себе можно пройти за год или меньше.
7. Что дальше
При прохождении курса я не смотрел ни на лево, ни на право. Вам я такое не советую. Уже ближе к концу Collection нужно понемногу начать осваивать вещи что не будут в курсе. Хотя, если вы не торопитесь, учите все постепенно, также как и я. Мой дальнейший путь скорее всего будет по этой ROADMAP. Думаю оно будет полезнее вам, чем 1000 лишних слов.
Спасибо что прочитали!
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ