RomanSo

Spring отлично справляется с функциями “клея” между архитектурными слоями Java-приложения, но реальность такова, что быстрая разработка действительно возможна именно при модульной компоновке функционала из отдельных небольших приложений, вернее, законченных наборов связанных функций. Это значительно больше чем компонентный состав архитектуры на уровне слоев, а именно - шаг к созданию модульной архитектуры приложения как таковой.

Да, это утопия. Можно посмотреть на судьбу EJB-бинов которые изначально позиционировались маркетологами именно как такие кирпичики-модули вашего приложения. На практике же реальная сложность взаимосвязей между бинами-сервисами приводит к тому, что крайне проблематично изменить их размещение между J2EE контейнерами после создания приложения равно как и попробовать такие “бины” использовать без дополнительной модификации – например, попробуйте продать их.



То есть, я хочу лишь подчеркнуть, что в большинстве случаев совершенно бесполезно пытаться на ранней стадии проекта надеяться, что большинство его модулей вы сможете повторно использовать позднее. Даже в однотипных проектах. Это лишь приведет к повышенным затратам ресурсов на следованиие внутренней конфигурации модулей на столько, что последующие разработчики приходят к выводу что “проще переписать чем понять” даже в рамках одного проекта. То есть вы НЕ будете писать то, за что вам платит заказчик, а столкнетесь с тем, что создаете некое свое приложение в котором заказанный и оплаченный фукционал – это лишь одна из его многочисленных фантастических опций, но, к сожалению, не основная и наиболее слабо продуманная и реализованная.

Если вы достаточно давно работаете в крупной “проектной кузнице кадров”, то вы уже должны были осознать, что при завершении одного проекта и переходу к следующему, даже из той же предметной области, все что вы можете реально использовать повторно это лишь ваш новый опыт, знание предметной области и файл log4j.xml. Все остальное, равно как организация ресурсов и конфигурацй, вы все-равно реорганизуете, так как будете уверены что “ну вот сейчас то я точно знаю как нужно было это делать”. Как мудро заметил старина Фаулер, в настоящий момент вы вступите в фазу рефакторинга, причем часто еще ненаписанного кода - вы начинаете оздавать новый проект переписыкая свои воспоминания о старом.

Наличие опыта уже выпущенных проектов приводит к тому, что вы создаете новый проект, а не развиваете старый – старый же будет еще какое-то время мучиться в холодных руках службы поддержки IT-отдела заказчика - лет 10, в лучшем случае. Вероятность того, что в проектной компании вы получите нескольких заказчиков на одинаковую систему, которую вы сможете длительное время развивать и обновлять у всех заказчиков одновременно, близка к нулю.

Наиболее распространенная ошибка архитектора в подобном случае это решени типа “ну вот теперь-то я созда-а-ам гениальный фраемворк и все будут его использовать и наступит полное счастье!”. Наступит полный финиш, поскольку этот нестандртный фраемворк будет постоянно недописан, никогда не будет должно задокументирован в онце-концов станет технологически и идеологически устревшим и вы будете прокляты вашими разработчиками, что будут вынуждены ему следовать. Вы разрабатывали кода-нибудь системы с использованием, к примеру, Documentum EMС? Ключевым моментом успешного внедрения такой системы неподготовленному предварительным опытом заказчику есть его уверенность (приобретенная после общения с вашим "продажником") в том, что ему нужна система на основе именно Documentum. Но это еще цветочки по сравнению с SAP R3 – это вообще используется исключительно из-за административной воли и индустриальной и/или юридической необходимости. И это еще хорошо задокументированные системы с программами обучения и сертификации! При этом ваше творческое развитие как разработчика превратится примерно в это



Но все меняется поностью если у вас есть не проект а продукт. Вы будете в ужасе – где привычные нам требования? Где проектный план? Где планове следование циклов итерационной разработки? А вот она – реальная жизнь программистов, движения пальцев которых действительно зарабатывают деньги. Привыкайте к настоящей жизни, выходите из ваших бесконечных «писюлек» из которых лишь 10% доходит до интенсивной эксплуатации реальным зказчиком. Возможно вы даже начнете понимать когда действительно полезен Agile.

Продукт же, как некий связанный набор сервисов, продается одновременно нескольким заказчиками и вы должны организовать процесс доработки существующего функционала и создания новых наборов функций таким образом, чтобы вы могли обладать возможностью сборки всей системы из набора отдельно разработанных и повторно используемых модулей, отличающихся лишь конфигурацией. Ровно постольку, поскольку у вас не будет зказчика у котрого будут присутствовать все модули – что-то да обязательно будет уникальным в силу необходимости выполнения интеграции с инфраструктурой заказчика. И ровно постольку, поскольку если вы не пойдете по описанному мной пути, вы неизменно получите набор из N независимых проектов, по количеству ваших заказчиков, и ваша команда будет невероятно занята внесением неcложных но взаимоислючающих требованй, исправлений и доработок во все эти проекты одновременно. Так как логический путь в развития событий таком случае это выделение некоего "ядра" системы, то наличие часто противоречащих требований от разных заказчиков пытаются втиснуть в это "ядро" и это приводит к тому, что ядро в конце-концов начитет состоять из взаимоисключающих "костылей" и если только-только починят один костыль, то моменально падает другой.



При этом менеджмент часто не понимает что плохого в том, что у нас N проектов, ведь одновременно над ними мы все-равно не работаем. Они даже заявляют - да это просто отлично что их ровно N, ведь мы можем вносить независимые изменения и проводить быстрые релизы! Это блеф - мы получаем необходимость иметь и актуализировать N наборов сценариев тестирования, столько же описания конфигов, туториалов, структур данных и целиком групп поддержки и рарзаботки (последнее самое сложное так как разработчики склонны периодически увольняться а новым придется вместо работы над одним проектом периодически отвлекаться еще на N-1 непонятных его разновидностей что вовсе не повысит их лояльность к компании и ускорит их бегство в Люксофт или Epam). Вместо этого гораздо интереснее развивать один продукт а заказчикам периодически устанавливать обновления, абсолютно бестплатно. Для нас плюс в том что мы подолжаем динамично развиват систему и всегда готовы вернуться к развитию конкрентного зказчика, а для старого заказчика наши бесплатные обновленияя, во-первых, просто приятны, во-вторых улучшают качетво его системы так как содержат багфиксы и, наконец, это лишний повод напомнить о себе не идиотской новогодней открыткой, а как о супер-команде (ну по-крайнй мере супер-ответственной команде, что уже плюс).

Я для себя нашел выход в виде организации модульной архитектуры (другого термина я пока не нашел, сорри), благо Maven и Spring всячески потворствуют таким желаниям. Множество вещей в данном случае должны быть организованы совершенно особенным, нестандартным с классической точки зрения человека (что прочел туториал) способом. Это и модульная (а не проектная) организация репозитория исходных кодов, и модульность баг-трекера и процедуры выпуска релизов и организации зависимостей и т.д. и т.п. Что же остается в проекте? Процедура его сборки из определенных версий базовых модулей + модулей конкретного зказчика, а также их конфигураия и локализированные ресурсы! Собственно в пректе заказчика должно быть только то что действительно относиться только к этому заказчику.

Надеюсь, я достаточно много сказал почему я считаю что будущее в продуктной разработке однозначно принадлежит компаниям перешедшим на конструирование и разработку функциональных модулей (часто под этим понимают SOA, но вообще-то это не так – я говорю о значительно меньших по размеру и более специфичных по назначению модулях). Остается добавить только одно – современные фраемворки чертовки плохо предназаначены для создания закончнных функциональных модулей. Решению основных встретившихся мне проблем (разумеется в контектсте ограниченного круга стоявших передо мною задач) я посвящу свои следующие посты.



Спокойной ночи.