Очень много людей, которые почитали книжку, приходят на собеседование джуна, мол, научите меня. Такие "джуны" никому не нужны, т.к. их учить очень дорого. Например, синьор может обучать до 5 джунов одновременно. На обучение джуна нужно 2-3 мес. Причем синьор не выполняет своих обязанностей в это время. Зп синьора 3,5к баксов. Получается, на обучение 5 человек тратятся 10к баксов, т.е. по 2к на человека. Добавьте к этой сумме зп джуна и стоимость его рабочего места, расходы на него. Получается 3-4к баксов. Причем пользы он не приносит, т.к. его код - это говнокод, который синьор постоянно перепроверяет и иногда исключает.
Вывод
Джун должен быть таким, который:
обучается сам
требует минимального контроля
знает великолепно java core
умеет искать информацию сам
задает правильные вопросы
не дергает по пустякам других программистов
знает обзорно технологии проекта
следует правилам написания кода, принятым в проекте, без отсебятины
быстро въезжает в проект
Требования к джуну на проекте:
отличное знание Java Core
самообучение
четкое формулирование проблемы
написание простых запросов SQL
распознавание в проекте ведущих технологий. Для большинства проектов:
сборка (Ant или Maven)
работа с базой данных - ORM (Hibernate, MyBatis и др.)
бизнес логика вклющая транзакционность (обычно Spring, необходимо понимание IoC)
клиент - масса фреймворков. Для веба желательно понимание основ HTML, CSS, JavaScript + часто либа JQuery.
Так что развивайтесь не только в джаве, и тогда быстрее станете программистом
Диана — в древнеримской мифологии богиня Луны и охоты. Всегда это имя завораживало :)
Но не буду отвлекаться, создательница темы безгранично права в жестокости и прагматичности текста представленной темы так же права в том, что кто предупреждён тот вооружён. Жизнь не любит слабых и тем более не любит паразитов, однако как сказал один великий полководец: лучшая тактика боя — тактика выживших.
Это говорит о том, что не стоит бояться нужно действовать, желание победить — это уже 70% победы, опыт обязательно придет более того — каждый настоящий мастер просто мечтает найти достойного ученика и передать ему свой опыт (только это секрет)!!!
Какая-то очень жесткая у вас контора/коллектив. Понятно, что от новичка будут ожидать стремление учится и разбираться самому, но у меня никогда не было проблем с тем, чтобы кто-то из коллектива не помог с вопросом/проблемой (конечно же вопрос должен быть задан корректно, но бывает, что и тупишь — никогда никто не отказывал, точно так же как и я потом не отказывал никому). Я бы даже сказал, что от новичка будут ТРЕБОВАТЬ задавать вопросы, ибо тот, кто их не задает, учиться гораздо медленнее и далает гораздо больше ошибок (хотя конечно тут тоже есть предел, правило золотой середины так сказать). А в остальном согласен с автором.
Нехило контора живет если может позволить снять сеньора с разработки. В нормальной ситуации это все выглядит по другому.
Пришел в команду скажем так неопытный разработчик. Месяц-два может три, тут как повезет, ему дают время прочитать спецификации касаемо кода, API, где что как используется, фреймворки и обще принятые практики. Паралельно устанавливает рабочию среду и все что с этим связано.
А дальше начинается самое интерестное. Допустим в фирме где придерживаются Agile методик разработки. Пусть будет Scrum к примеру. Получаем каждый разработчик имеет 1-2 must задания, 1-2 should, 1-2 could на каждый time box + фиксить баги и проводить код ревью, это не говоря о разных grooming sessions и тп. Конечно цифры могут разнится, но не суть важно. Бизнесс аналист придумал какую нить фишку, дал на нёё к примеру 2 тайм бокса. Итог получаем все разработчики по уши в работе. И кто простите будет сидеть над новичком и говорить ему что тот будет делать, когда для каждого менеджера и тим лида важно чтобы все must были сданы в срок.
Так что если планируете идти в разработку, готовтесь к тому что, никто с вами не будет сидеть, так что да Самообучение must have skill, и постоянно отрывать от работы своих коллег не очень красиво и может даже где то унизительно.
Однако не все так плохо.
Если вас взяли на работу, значит потенциал у вас есть и все будет ок. Разного рода GIT и тп, может надо учить может не надо. Любая среда разработки сегодня справляется на ура с Push, merge, commit, fetch, synchronize. То же логирование, если компания пользуется best practice, то скорее всего логирование будет на уровне анотаций, интерсепторов или еще чего.
Насчет тестирования опять же. Скоре всего ваши коллеги уже написали фреймворк для тестирования всего и вся. Останется только прочитать документацию и глянуть как ваши колеги писали код для одного или другого типа классов. Соглашусь jUnit + Mockito стоит знать хотя бы чтобы на интревью было что рассказать.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Но не буду отвлекаться, создательница темы безгранично права в жестокости и прагматичности текста представленной темы так же права в том, что кто предупреждён тот вооружён. Жизнь не любит слабых и тем более не любит паразитов, однако как сказал один великий полководец: лучшая тактика боя — тактика выживших.
Это говорит о том, что не стоит бояться нужно действовать, желание победить — это уже 70% победы, опыт обязательно придет более того — каждый настоящий мастер просто мечтает найти достойного ученика и передать ему свой опыт (только это секрет)!!!
Пришел в команду скажем так неопытный разработчик. Месяц-два может три, тут как повезет, ему дают время прочитать спецификации касаемо кода, API, где что как используется, фреймворки и обще принятые практики. Паралельно устанавливает рабочию среду и все что с этим связано.
А дальше начинается самое интерестное. Допустим в фирме где придерживаются Agile методик разработки. Пусть будет Scrum к примеру. Получаем каждый разработчик имеет 1-2 must задания, 1-2 should, 1-2 could на каждый time box + фиксить баги и проводить код ревью, это не говоря о разных grooming sessions и тп. Конечно цифры могут разнится, но не суть важно. Бизнесс аналист придумал какую нить фишку, дал на нёё к примеру 2 тайм бокса. Итог получаем все разработчики по уши в работе. И кто простите будет сидеть над новичком и говорить ему что тот будет делать, когда для каждого менеджера и тим лида важно чтобы все must были сданы в срок.
Так что если планируете идти в разработку, готовтесь к тому что, никто с вами не будет сидеть, так что да Самообучение must have skill, и постоянно отрывать от работы своих коллег не очень красиво и может даже где то унизительно.
Однако не все так плохо.
Если вас взяли на работу, значит потенциал у вас есть и все будет ок. Разного рода GIT и тп, может надо учить может не надо. Любая среда разработки сегодня справляется на ура с Push, merge, commit, fetch, synchronize. То же логирование, если компания пользуется best practice, то скорее всего логирование будет на уровне анотаций, интерсепторов или еще чего.
Насчет тестирования опять же. Скоре всего ваши коллеги уже написали фреймворк для тестирования всего и вся. Останется только прочитать документацию и глянуть как ваши колеги писали код для одного или другого типа классов. Соглашусь jUnit + Mockito стоит знать хотя бы чтобы на интревью было что рассказать.
* логирование (Logback/Log4j)
* дебаг