Rauf Aliev (rauf) wrote,
Rauf Aliev
rauf

Искусство программирования под Unix (и не только). Часть третья, «правило композиции»

Продолжаю цикл статей на тему «Искусство программирования под Unix» Эрика Раймонда. Ранее я упоминал первые два правила — модульности и ясности.
Сегодня речь пойдет о третьем правиле —

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

К сожалению, как в Windows, так и Unix, желание разработчиков «изобрести велосипед», создать и утвердить свой стандарт, выделиться на рынке, создает такое количество разнородных интерфейсов, что ни о каком практическом соединении программ не может быть и речи.

Здесь очень уместно вспомнить концепцию сервисно-ориентированной архитектуры, SOA. Согласно ей, каждая программа, по сути, сервис, имеет стандартный интерфейс, в идеале еще и совместимый с существующими. Такой подход позволяет многократно использовать компоненты, позволяет проводить автоматизированное внешнее тестирование сервисов. И немаловажно, что в SOA детали реализации скрыты — например, сервис может быть разработан на более специфичном задаче языке программирования.

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

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

В таких условиях среди них находятся свои «кулибины», что может принести и проблемы. Например, можно вспомнить Gdrive — виртуальный интернет-диск, в котором хранилище организовано на основе мейл-сервиса GMail. Очевидно, такое использование почтового сервиса идет ему во вред. Или вот еще — интерфейс IMAP в Gmail мне раньше неплохо помогал резервировать локальную почту в гугловских почтовых ящиках, заодно автоматически их индексируя. Я делал это, используя Outlook, просто копируя почту из аккаунта в аккаунт, а после настраивая пересылку. Сейчас «дыру» с массовым аплоадом закрыли.

Очень важно найти сразу партнера, кто бы чуть ли не на нулевом этапе подхватил бы ваш API и участвовал в его проектировании и, может быть, реализации. Только так можно «услышать» пользователей, а не додумывать за них то, что им нужно.

Большой ошибкой является разработка API по принципу «лишь бы был». Без документации, без единообразия в применении, без единой логики, объединяющей различные варианты его использования, без це лостной архитектуры, польза от сервиса будет очень условной. В качестве отрицательных примеров можно вспомнить омгэшную CORBA и майкрософтовский COM — довольно плохо проработанные технологии для связывания разнородных систем. Разработкой спецификации CORBA занимался десяток компаний первого эшелона, но получилось то, что получилось: на мой взгляд, ни один вменяемый программист по собственной воле сегодня эту концепцию не выберет. А COM имеет довольно узкое применение для связи программ в среде MS Windows, хотя никто не мешал его с самого начала разработать более универсальным.

В мире Unix, для взаимодействия консольных программ есть технология каналов (pipe), о которой я уже писал раньше. Выход одной программы направляется на вход другой, и на совести «архитектора» таких связок — правильно их друг с другом состыковать. Выходит что-то типа конструктора, собрать из которого что-то полезное по рукам специалисту даже без понимания как работает каждый из «кирпичиков». Концепция pipe-ов довольно примитивна, но идеальна подходит для широкого круга задач узкой предметной области. Когда ее пытаются переложить на все подряд, возникают проблемы, потому что выбран не тот «инструмент». Майкрософт, например, в своей реализации пайпов в powershell добавила объектность, что потенциально должно было сделать их супергибкими. Но простые решения, как говорится, «рулят». И где сейчас этот powershell…

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

Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments