Технологическая гамма - с чего начать и как?

Question

Я хочу стать архитектором J2EE в будущем.

Я начал изучать новые технологии и рассмотрел некоторые фреймворки, такие как Spring, Struts и Hibernate. EJB также я работал в прошлом (еще в 2005 году).

Вещи, я не работал много

• Передовые технологии (AJAX, FLEX, FLASH и т. Д.)
• Методы повышения производительности
• Последние изменения в EJBs / JPA
• JCA
• JMS
• Веб-сервисы
• Лучшие инструменты, которые можно использовать в SDLC .. (например: ANT / Hudson для сборки, JMeter для тестирования, PMD для проверки кода и т. Д.)

Я планировал выпустить план, охватывающий эти технологии и некоторые достойные инструменты, которые могут пригодиться при разработке.

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

Я недавно начал с AJAX ... потратил 3-4 дня на изучение различных наборов инструментов для AJAX, таких как DOJO, JQuery и т. Д. В конце обучения я получил четкое представление о том, как работает AJAX, но я не знаю, так ли это знание завершает мое обучение? Затем я посмотрел на некоторые инструменты для CI. Провел 3-4 дня с Хадсоном и ANT. У меня была приличная идея о том, как это работает, но опять же не уверен, что этих знаний достаточно для завершения моего обучения. Каждая такая вещь имеет достаточную глубину, и если я углублюсь в них ... это может занять месяц или даже больше. Я планирую завершить SCEA в следующие 6 месяцев, но, не зная об этом, я считаю, что SCEA не принесет никакой пользы.

Мой вопрос,

1. Есть ли какая-то проблема с моим подходом, или все сталкиваются с этой проблемой?
2. Когда я начинаю знать о технологии, в конце концов… каков должен быть мой результат? (Знание технологии является очевидным ответом, но сохраняете ли вы список пунктов, которые вы пытаетесь выяснить, работая над технологиями?)

Спасибо за чтение,

Answer 1

Одна из проблем, связанных с приобретением опыта в J2EE, заключается в том, что это «движущаяся цель» - все время появляются новые технологии, API постоянно меняются, и в дополнение к знанию API Sun вы должны знать множество сторонних инструментов, которые сейчас практически неотъемлемая часть стека. Как Hibernate, Spring, Hadoop и все такое.

Резюме J2EE или список вакансий часто распознается супом Buzzword, который часто охватывает строки за строкой за строкой.

Для новичков это сопряжено с тремя рисками: - Изучение устаревших технологий. - Изучение решений конкретных поставщиков без понимания альтернатив и принципов, лежащих в их основе. - Вы можете изучить много инструментов, но никогда не знаете, как их смешать. - Никогда не получайте шанс попрактиковаться в программировании и развить «инстинкт программиста».

Вы не особо упомянули о своем опыте, поэтому неясно, насколько у вас есть опыт работы с Java на Java или насколько вы удобны в задачах, не связанных с архитектурой.

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

Давайте возьмем, например, AJAX или архитектуру обмена сообщениями. Попробуйте записать описание различий между двумя поставщиками или фреймворками. Теперь попробуйте некоторое время использовать низкоуровневые конструкции, такие как XmlRpc, GWT или сервлеты, прежде чем сосредоточиться на освоении предполагаемого комплексного решения. Точно так же поиграйтесь с сокетами или API-интерфейсами JMS, прежде чем использовать архитектуру обмена сообщениями и т. Д. Поиграйте немного с SQL, прежде чем переходить в спящий режим или другие ORM. Теперь посмотрим, сможете ли вы привести более убедительные аргументы в пользу различий между фреймворками.

Я не могу сказать вам, сколько знакомых мне архитекторов J2EE провалили собеседования, потому что они не смогли решить простую проблему FizzBuzz.