Предлагаю собрать в данной теме разбросанные по всему форуму крупицы информации о том, какими знаниями необходимо обладать программисту, желающему устроиться на работу в должности стажера (самое начало карьеры) по направлению разработки корпоративного ПО на Java. Подчеркну: только корпоративного ПО, а не сайтов, инет-магазинов и пр.

Проанализировав несколько десятков подходящих объявлений о приеме на работу, я выделил примерный список того, что работодатели требуют в обязательном порядке:

• Java (как язык программирования)
• J2EE, а конкретнее:
  а) JDBC
  б) EJB
  в) Servlet
  г) JSP
• SQL
• составление документации

Достаточно ли этого? Может быть нужно что-то добавить\убавить? Понятно что у каждого работодателя свои требования, однако очень хотелось бы видеть некий усредненный список. Он очень поможет начинающим разработчикам тем, что они будут знать, что конкретно им нужно изучать для успешного приема на работу.

Особое внимание хочу обратить на то, что означенный список должен определять исключительно минимальный (базовый) уровень, необходимый для входа в мир корпоративного ПО. Конечно, Velocity, Spring Framework и прочие модные штучки это очень здорово, но сперва нужно заложить некоторое основание. Вот именно его и хотелось бы видеть в данной теме.

Заранее благодарю за участие!


Добавлено: по результатам обсуждения окончательный вариант списка выглядит примерно так:

- твердо знать:

• Java (как язык программирования)
• SQL
• javadoc
• CVS
• J2SE (основные средства стандартной библиотеки)
• ant
• JUnit
• servlets
• JSP

- иметь представление:

• MVC
• spring\strust framework
• hibernate
• JSF
• JMS // надо ли?
• EJB
• web-services
• дополнительные средства документации (TWiki, OpenOffice)

Это сообщение отредактировал(а) rsm - 5.7.2007, 09:49

SQL подразумевается.
Для минимального уровня знаний, имхо, наличие с списке сервлетов и JSP спорно. Скорее "очень желательно", чем "необходимо". Да и составление документации тут не к месту. Мой опыт показывает, что кодеры не умеют писать документацию, а те, кто умеет её писать, либо не умеют кодить, либо делают это плохо (исключения бывают, но это всего лишь редкие исключения из правила).

Логично, добавил.


А если разрабатываемое ПО имеет web-интерфейс? Что, кстати, совсем не редость (а скорее даже правило) для корпоративок.


Кто ж тогда ее пишет? 

Это как? Львиная доля корпоративного ПО имеет веб интерфейс. Даже сам написал:



а с сайтами возиться не хочешь.   

Впрочем, позволю себе высказать свое IMHO:
Лучше выбрать одно J2EE направление и быть гуру в нем, а не рассеиваться по всему сразу. Например View Tier (HTML, AJAX, Servlet, JSP, JSF, Java Script ...) или Business Tier (Spring, EJB, Web Services, Quartz ...) или Data Tier (SQL, XML, Hibernate, Java Persistence, XQuery, Lucene...)  Это я говорю по тому, что J2EE невероятна большая и динамично развивающаяся технология. Знания устаревают на днях. То что было современно 3 года назад сейчас уже никому нужно. Только если в команду поддержки ПО не попадешь. Выучить все очень непросто, а эксперты везде нужны... Хотя, конечно же, как минимум, ознакомленным нужно быть со всем...

Добавлено через 52 секунды

Technical Writer

ну и какую же выбрать?


кодеры пишут тест-кейсы , так что 

всё таки надо

Пардон, но насколько мне известно, web-интерфейс только выглядит как сайт, но таковым вовсе не является. В первую очередь потому, что корпоративное ПО предназначено исключительно для внутреннего использования. А сайт доступен всегда и для всех. Конечно и в корпоративке можно сделать отдельный пользовательский интерфейс, который будет сообщаться с внешним миром, но это будет опять таки не сайт, а лишь часть корпоративки.


А всегда ли это приемлемо для работодателя? ИМХО очень даже редко приемлемо. Потому что настолько тонкое разделение направлений может быть только в очень большом коллективе, а компаний подходящего масштаба в мире не так много.

Это уже скатывается к дискуссии, что есть "сайт", а что - "вэб-интерфейс". Имхо, многие корпоративные проекты имеют не только вэб-интерфейс, но и полнофункциональную структуру сайта.


Смотря, чего хочет работодатель. Если он хочет мальчика на побегушках, который будет латать дыры в проекте - нужен человек, который сносно разбирается во всём. Если он желает создавать современные продукты с высоким качеством - придётся искать специалистов.


Хм... три человека - это много? А ведь разделение будет уже достаточным, чтобы они успешно выполняли проекты. Конечно, если это будут специалисты, а не новички.

Какая больше нравится, ту и выбирай.   


Лично для меня, web интерфейс и сайт это одно и тоже. Поскольку работать с ним приходится через Web-браузер. Технология все равно сводятся к отправке HTML разметки браузеру клиента. Или клиент это не браузер, а GUI программа?


Не думаю что всегда. Все от организации труда в конторе зависит. Бывают большие конторы и большие проекты, а бывают не очень. Бывают команды где 15 студентов и пару матерых спецов, а бывают где штук 7 спецов и все. Просто последние везде нужны. Это факт. 
Впрочем я конечно же не утверждаю, что нужно обязательно учить что-то одно... можно все и сразу. Это как ты сам хочешь: в ширь или в глубь копать.

P.S:
Вот я в своем первом посте написал 16 различных технологий (причем далеко еще не все). Даже если уделять каждой на серьезное изучение по 1 месяцу то уйдет примерно полтора года (хотя тут от человека сильно зависит). За полтора года, выйдут новые версии библиотек и где поменяют (добавят фитч) процентов на 20, или придут более "модные" технологии. А если чем то постоянно не пользоваться то это забывается, значит все нужно заново повторять. Мне вообще парой кажется, что людей разрабатывающих новые технологии гораздо больше чем их использующих  Вывод могу сделать такой: Хочешь трудится в j2ee сфере готовься к постоянному самообразованию. 

Добавлю свои 5 копеек. 

Во-первых, я бы разделил технологии (стандарты) и их реализации. Например, сервлеты и JSP - это технологии, а Tomcat, Jetty, Resin - это реализации. Предполагается, что веб-приложение, написанное с помощью JSP и сервлетов будет работать с любой реализацией. Если рассматривать Tomcat и Jetty, то я почти уверен, что так и будет, если же тоже самое приложение попытаться запустить на IBM Websphere, я бы поостерегся говорить так однозначно. Мораль - любая реализация обладает своими особенностями, которые в общем-то нужно знать, но приходит это с опытом. И в первую очередь нужно знать технологии.  

Во-вторых, рассмотрим те же JSP и сервлеты. Это те технологии, которые точно нужно знать если ты собираешься разрабатывать веб-приложения. Но! Их точно нужно знать если ты в ближайшем будущем собираешься участвовать в разработке коммерческих проектов. Есть множество людей, убежденных, что Velocity - гораздо лучшая альтернатива JSP (я в их числе), тем не менее в работе приходится использовать JSP и ни что иное. По той простой причине, что это стандарт де-факто и пиарится Sun, хотя может быть и использование Velocity было бы гораздо более эффективным. Поэтому для участия в коммерческих проектах (если конечно, не ты сам организатор проекта и не определяешь чем пользоваться), нужно знать стандартные вещи - JSP, сервлеты, JMS, веб-сервисы и т.п.

В третьих, специализация на каком-то одном tier может быть и верна, но на самом раннем этапе карьеры программиста. Велика вероятность того, что при переходе на новый проект ты скажешь, что хочешь заниматься data tier, а менеджер проекта тебе ответит: "Да у меня таких уже 5 человек, а займись-ка ты, дружок, веб-вервисами". Думаю, иметь представление нужно обо всем. И готовиться постоянно изучать что-то новое. Честно скажу, заниматься этим приходится ежедневно. Долго продержаться с каким-то ограниченным запасом знаний вряд ли представляется возможным. Мой небольшой опыт программирования на Delphi когда-то убедил меня в том, что можно наизусть знать все API и писать не заглядывая в документацию. Так вот, с J2EE так не пройдет, здесь помнить все - не в человеческих силах, всего очень много, при этом это самое "все" постоянно меняется.

В-четвертых, писать документацию таки надо уметь, полезно для себя же. Через полгода бывает сложно разобраться в своем собственном коде. Хоть у меня и большой опыт в J2EE, в коммерческих проектах я участвую относительно недолгое время. Тем не менее, видел и свой проект и несколько параллельных. У меня такое ощущение, что технический писатель - это некая мифическая личность, которую никто никогда не видел. Допускаю, что где-то такие специально обученные люди есть, я же всегда документацию писал сам.

Ну и последнее. Все-таки, самый быстрый путь изучения - это туториал от Sun. Единственное "но" - тот сервер приложений, который у них используется в примерах (Sun application server) на практике встречается очень редко, скорее всего придется переходить на что-то другое.

Нет, они существуют, но "сырьё" для них всё равно должен предоставлять разработчик.


Неужели отличия достаточно значительны?

Нет конечно, технологии везде одни и те же. Но иногда там описываются вещи, которые генерируются или создаются инструментами SAP. Средства других серверов приложений могут сильно отличаются.

Как я понимаю, дело обстоит обратным образом: то, что запускается на Tomcat, должно запускаться везде, потому что Tomcat это reference implementation - эталон - для спецификаций servlets&JSP. Если кто-то говорит, что он эти спецификации реализует, то все, что запускается на Tomcat, должно запускаться и у него. 

С другой стороны, то, что разработано под некоторым application server (WebSphere, WebLogic, JBoss, SAP) - может быть (скорее даже - "чаще всего") непереносимо (по меньшей мере, без дополнительных трудностей).

Добавлено @ 14:02

+1


Это сообщение отредактировал(а) Ulysses4j - 26.6.2007, 14:34

Согласен, в Tomcat об этом говорят. Скорее всего, потому что Tomcat разрабатывают сотрудники Sun.


Где такое написано? Серверы приложений J2EE проходят соответствующую сертификацию у Sun. В процессе сертификации, насколько я знаю, не сказано, что веб-контейнер должен работать идентитично Tomcat.


Как я понимаю, если сервер приложений прошел сертификацию у Sun, то приложения должны быть переносимы, за исключением деталей, которые зависимы от разработчика (они явно указаны в спецификации). Тогда мне совершенно не понятно почему в Websphere 6.1 ранних версий жизненный цикл обработки запроса не соответствует спецификации, хотя Websphere сертификацию прошел.

В смысле, это те сотрудники, которые по совместительству состоят в ASF? ;)


Каюсь, ссылку привести не могу.


Этого не сказал и я: я не говорил, что работать должны идентично, я сказал, что то, что запускатся на Tomcat, должно запускать в других местах, потому что Tomcat  предоставляет минимальную функциональность сервлет-контейнера, а app-серверы - надмножество этой функциональности:

Все, что я сказал выше, в основном вытекает из этого представления о надмножестве. 

Про ситуацию с WebSphere ничего сказать не могу.

ЗЫ Это все, наверное, жуткий оффтоп пошел. Прошу прощения. Надеюсь, мы как-то остановимся.

Это сообщение отредактировал(а) Ulysses4j - 26.6.2007, 19:04

Главное, чтобы интересно было. И это правило соблюдено