О сервис ориентированных архитектурах

Ниже следует мое понимание сервис-ориентированных архитектур. Откуда они берутся и как их стоит проектировать.

Начнем издалека. Допустим, у нас есть желание заиметь интернет-магазин. Предприниматель Вася заказал программисту Пете сделать ему сайт, где бы он мог торговать своими товарами. Петя, не долго думая, выбрал свой любимый LAMP (Linux/Apache/MySQL/PHP) и через месяц выдал архив с кодом и инструкцию по установке.

Последовательность

Про то, как общечеловеческое стремление быть последовательными влияет на работу программистов и может быть использовано в работе менеджера.

Люди любят быть последовательными. Очень любят. С последовательностью ассоциированы такие положительно окрашенные вещи, как честность, постоянство, надежность. А с непоследовательностью ассоциированы такие отрицательные штуки, как непостоянство, неуверенность, отсутствие собственного мнения.

Продолжение разговора про Spring IoC Framework

В первой статье я задекларировал, что есть три подхода к написанию приложений в Java, если рассматривать разработку с позиции DI:

• писать, не используя DI — код более простой и понятный, но менее гибкий;
• писать код, используя DI, и дополнительно писать Java код, который связывает компоненты;
• писать код, используя DI, и связывать компоненты с помощью конфугарационных файлов в XML.

Для меня интересным является то, что все три подхода можно использовать в одном приложении. Можно к примеру в мелких модулях, которые возможно протестировать целиком, не применять DI, более крупные компоненты собрать с помощью Java-кода, а там, где уместно дать пользователю возможность выбирать из нескольких альтернативных реализаций использовать конфигурационный файл и Spring IoC.

Чтобы лучше понимать взаимоотношения и выбирать оптимальное соотношение между Spring IoC Framework и Java кодом, я часто рассматриваю Spring IoC не как "фреймворк", который инициализирует мое приложение и вызывает нужные методы, а как примитивный, динамический, интерпретируемый язык программирования предназначенный для того, чтобы скриптовать инициализацию Java приложений. Нам нужно скриптование в этом месте при инициализации — используем IoC. Не нужно скриптование — не усложняем наше приложение без необходимости.

Каждая новая версия должна приносить больше прибыли, иначе зачем мы ее внедряли?

Заголовок статьи может показаться самоочевидным. Но вот однажды я встретил прямо буквальное применение это принципа.

Я консультировал по CI (Continuous Integration) вопросам одну компанию, что занималась показом рекламных баннеров в интернет. Там довольно много интересных задач. Пока браузер не спеша загружает страницу надо понять, что это за пользователь, где он обычно бывает, какие товары и услуги недавно искал, оценить сколько стоит, выставить на аукцион, продать, показать баннер. Или наоборот покупать пользователей на аукционе. В общем я не вникал во все это очень подробно - задача стояла другая.

А задача у меня была в оптимизации развертывания свежего кода в продакшен. Путь от написания кода до использования его в продакшен был у них очень быстрым. Код мог быть написанным, протестированным и начать работать в самые короткие сроки. Чтобы не облажаться они научились отводить небольшой поток пользователей на новую версию приложений, тогда как основная масса пользователей работала по-старому (да, все мы знаем про rolling-updates). Это позволяло тестировать приложение на реальных случаях и на настоящей нагрузке, откатывать изменения, если что-то пошло не так, или наоборот распространять это по всему кластеру.

Что интересно, это что когда они тестировали свои алгоритмы, то смотрели, сколько дохода приносит новый код, то есть проверка увеличения доходности (или снижения издержек) тоже была одним из тестов! Больше я нигде этого не видел. Хотя работал во многих проектах, где это можно было бы успешно внедрить. Да каждый крупный онлайн магазин мог бы таким образом проверять насколько хороший код они подготовили. Но не делают. То ли не видят смысла то ли считают, что забот по организации подобной инфраструктуры слишком много и они не будут оправданны.

IoC Spring Framework

Поговорим о IoC Spring Framework. Дело в том, что меня совсем не радует его использование во всех Java проектах, в которых я имел честь участвовать.

Начнем с того, что сам по себе инструмент не плох. Но вот его использование - это зачастую ужас. Чтобы что-то правильно использовать надо хорошо понимать для чего эта штука создана и где она помогает и где мешает. Хочу попытаться это сформулировать.

Собеседование на работу

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

В нашей компании кроме технического отзыва принято еще давать свое мнение о том, как человек себя держит и общается. Хотим ли мы его видеть в нашем коллективе и т. п. Что можно сказать о этой оценке. Возможно ли что-то понять о человеке за 1-2 часа стандартного собеседования?

Огрупленное мышление

Я долгое время работаю в разных компаниях, основной деятельностью которых является написание программного обеспечения. Часто в таких компаниях процессами руководят выходцы из программистов. Существует много споров о том является ли это наиболее эффективным или нет. Но есть одна вещь, в которой я абсолютно убежден: программисты будут организовывать деятельность себе подобных лучше, если дополнительно будут знать некоторые факты из других дисциплин. Например из психологии.

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