Эта статья является кратким историческим обзором прогресса Java EE на протяжении многих лет. Это введение из книги по архитектуре Java EE .
Несколько лет назад, когда я начал свою первую работу в области ИТ, я и я были молоды и незрелы. Я был старшим в Университете Висконсина, занимаясь хакерством C ++ и MFC по ночам, чтобы получить степень CS. Днем я был пионером Java в крупной американской финансовой ИТ-фирме, которая оплатила мой колледж. Sun и Microsoft боролись с Java в судах. JBuilder и Visual J ++ управляли миром IDE. Eclipse Foundation еще даже не существовало, появившись несколько лет спустя. Ведение журнала было безумно больно с System.out. Дженериков не было. В отсутствие JSR-175 (аннотации) метаданные синтетического источника были ограничены несколькими пользовательскими компиляторами. ORM был мечтой каждого разработчика JDBC, который знал, что им нужен какой-то уровень абстракции драйвера, но не знал, что именно.Я помню, как спал ночью после 12 часов кодирования, пытаясь переварить в глубоком сне этих бесчисленных:
try { // to run a sql query
}
catch { // any exceptions
}
finally { connection.close(); }На этой ноте шаблон DAO был благородной идеей, которая при правильном использовании принесла вам заслуженное повышение. Сервлеты были большим улучшением по сравнению с CGI1, в то время как концепция веб-фреймворка была настолько же реальной, как и решение для дома; и EJB были быстро растущим зверем, более тяжелым, чем Кинг-Конг.
Что касается меня, у меня была мечта стать архитектором решений Java … Изучение языка Java и экосистемы J2EE, несмотря на медленный процесс, оказалось гораздо проще, чем овладение навыками, необходимыми для правильной разработки полного решения Java. Потребовались годы кодирования, проектирования, написания спецификаций, тестирования производительности, интервью с пользователями, собраний и даже социальных собраний, чтобы по-настоящему овладеть архитектурой системы. Лучшее, что я могу сказать, это:
Каждый архитектор должен быть в состоянии выполнить работу разработчика, если это необходимо, но обратное не всегда верно.
Кажется очевидным, но вы будете удивлены, сколько архитекторов — буквально, людей, имеющих такое звание, я встречал в корпоративной среде; не удалось реализовать подсистему Java, когда у проекта не хватало разработчиков и требовались дополнительные мозги для ускорения процесса кодирования. Обратите внимание, что в других отраслях это правило не должно соблюдаться. Например, в строительстве архитектору, строителю или застройщику не нужно подробно знать работу друг друга. В бизнесе программного обеспечения архитектор обязательно должен иметь опыт разработчика. Да, в старые времена корпоративная Java была ужасно болезненной, например, EJB (1 и 2). Я видел, как многие команды буквально разделялись на группы, специализирующиеся на одной подсистеме J2EE, но делали это хорошо. Была команда MVC, разделенная между UI и парнями из Servlet.Была команда EJB, разделенная на свои подгруппы. Я даже видел преданную команду DAO! С развитием Java на протяжении многих лет, такое разделение команды не является необходимым. Тем не менее, современный архитектор должен быть универсальным разработчиком, способным предоставить законченное решение, с нуля, и все самостоятельно, если это будет необходимо.
Современные JVM быстрее, чем что-либо в прошлом, сопоставимы с традиционными скоростными королями, такими как C / C ++, благодаря JIT2, продвинутым алгоритмам GC3 и другим способам оптимизации. Аннотации и средства улучшения байт-кода4 принесли нам фреймворки и библиотеки, которые, кажется, делают магию. Шаблоны проектирования 5 окружают нас, и если вы не можете применить самые популярные, вы даже не будете восприниматься всерьез как разработчик, а тем более архитектор. Инъекция зависимости, пожалуй, самая распространенная, и мальчик, она стала элегантной. Простой, но великолепный:
@Inject private MyResource whatever;У вас под рукой есть то, что в прошлом требовало громоздкого XML-кода. Конечно, в зависимости от каркаса, контейнера или спецификации механизм аннотации DI6 может немного отличаться. Например, в Tapestry IOC инъекции выполняются с помощью @Inject, @InjectPage или @InjectService. Guice делает это с @Inject, в то время как спецификация EJB дает вам @EJB. Пока мы находимся на предмете зависимости, давайте не будем забывать о печально известных историях ужасов об аффилированных зависимостях JAR, которые раньше были кошмаром развертывания каждого разработчика. Затем Мэйвен вышел, как Санта, из камина и взял штурмом проблему, превратив ее в пережиток прошлого. Сегодня Maven — это ключевой инструмент в арсенале каждого разработчика, а также плагин «не могу жить без» в современных средах разработки, таких как Eclipse или Netbeans. Соглашение о конфигурации сделало кодирование безопаснее, быстрее и приятнее.Современные IDE бесплатны, мощны и стабильны. ORM здесь как граждане первого класса, бесплатные, стандартизированные (JPA), с большим количеством реализаций на выбор. Что касается EJB, с версией 3 они стали легче, но мощнее, чем когда-либо прежде.
На стороне ресурса у нас есть StackOverflow, StackExchange и другие сайты QnA, которые облегчают поиск исключений и ошибок. Эти инструменты были не так легко доступны в старые времена; мы, кажется, принимаем их как должное. Хороших учебных пособий было мало, и в то время как все прыгали в сторону программирования, старомодные книги были лучшим средством для изучения. Тем не менее, некоторые вещи не изменились. Вы не можете просто гуглить «как стать архитектором Java», как если бы вы искали LazyInitializationException. В то время как последний даст вам множество результатов, сразу намекающих на проблему, первый даст вам в лучшем случае несколько определений и продвинутых учебных пособий по Java EE. Причина в том, конечно:
Невозможно дать количественную оценку чего-то вроде архитектуры программного обеспечения в одном учебном пособии, которое по завершению внезапно превратит человека в архитектора.
Я знаю, что эта книга также не сделает вас архитектором, но это будет ресурс по той теме, которую я хотел бы иметь, когда мне это было нужно больше всего, и которую я до сих пор не могу найти нигде в Интернете.
Так что же нужно, чтобы стать архитектором в индустрии программного обеспечения? Мы подробно рассмотрим этот ответ, но, как мы уже говорили, архитектор — это особый вид разработчика. Архитектор программного обеспечения — это как поэт литературы. Архитектор способен писать красивый код, дополненный еще более великолепным JavaDoc, который читается как поток поэтического шедевра. Это человек с видением, опытом, глубоким пониманием экосистемы Java, спокойной личностью, превосходным общением — как письменным, так и устным; мотиватор, командный игрок, провидец и лидер. Это всего лишь несколько характеристик, которые я могу вспомнить, как вы поймете, их гораздо больше.