Пользователь
0,0
рейтинг
30 августа 2010 в 11:09

Разработка → Искусство программирования под 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…

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

« Ранее: правило ясности Продолжение: правило разделения »
Рауф Алиев @raliev
карма
130,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (14)

  • 0
    Ну, там есть и обратная проблема. Что может быть проще, чем XML RPC over HTTP?… и это вместо plaintext pipe'а. Когда есть готовые библиотеки очень легко можно застрять в мире высоких абстракций, не замечая того оверхеда, что внизу. (не замечая до определённого момента).
    • 0
      В целом — да. С другой стороны, железо стоит дешево, а люди — дорого. Лучше, когда система требует не два сервера, а пять, чем когда она быстрая и производительная, но ни один программист не может быстро ответить, можно ли в принципе реализовать какое-либо изменение, не говоря уже о том, сколько на это уйдет времени по его оценке.
      • 0
        Железо стоит дёшево в количестве 1шт. Когда речь идёт о том, будет внутри железки 1ГГц процессор или 300МГц (и это всё от одной батарейки), то нет, железо стоит очень дорого.
        • 0
          я сервера имел ввиду, конечно. Если программно-аппаратное решение разрабатывается, там подход, конечно, должен учитывать требования к производительности, энергопотреблению, теплоотдаче и многому другому… Там тонкостей вообще до фига. А для сайтов-сервисов лучше добавить еще один (два, пять) сервера, зато иметь красивую и прозрачную архитектуру, чем оптимизировать донельзя, чтобы потом любое изменение было целым проектом… Я тут недавно с одними людьми общался, руководителями интернет-магазина, так у них он развернут, по его словам, на сорока серверах. Мне вообще очень сложно представить, что же там такое должно быть, чтобы не хватило 2-4 серверов. Но для 2-4 серверов написать софт, способный перерабатывать несколько миллионов хитов очень непросто. Поэтому обычно такие магазины ставят на 5-8 серверов и их достаточно по уши (у нас осенью так будет). Так вот, если есть выбор — оптимизировать ПО в ущерб архитектурной целостности и supportability, в ущерб стоимости поддержки и развития, или добавить пару серверов и ничего не трогать, то лучше выбрать второе. А трогать уже без спешки — проводить рефакторинг, взвешивая каждое изменение.
  • 0
    Вообще в универсальности интерфейса есть и недостаток: он может быть недостаточно гибок
    • 0
      Возможно, но тогда это повод пересмотреть архитектуру и сделать усложнение правильно. Без этого подхода решение простое — например, одна система просто напрямую обращается через SQL-запросы к другой. Выходит гибко-гибко. Но любое изменение структуры БД выходит очень трудоемким процессом. Если же делать через веб-интерфейсы, в какой-то момент понимаешь, что сервиса не хватает и пересматриваешь архитектуру. Это может повлечь больших затрат на проект, зато меньших — на поддержку.
      • 0
        тут вспоминается старый спор ликусоидов по поводу zfs: зачем SUN продублировала там почти все подсистемы по работе с кэшом и устрйоствами

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

    Сейчас, по-моему, уже мало кто без необходимости (жёсткие требования к размерам и/или скорости обработки, например СУБД) пользуется своими форматами (как правило бинарными с неизвестной структурой), да ещё и не предоставляя экспорта хотя бы в одном «приличном» формате. По крайней мере в большинстве приложений, с которыми я сталкивался в последнее время (десктопные, серверные и веб-приложения), данные хотя бы экспортируются/импортируются в/из CSV, XML, YAML, JSON и т. п. Неужели ещё кто-то не понимает, что возможность интеграции с другими продуктами — это плюс для своего продукта, а не продуктов конкурентов?
  • –1
    Ну вот опять.

    В качестве отрицательных примеров можно вспомнить омгэшную CORBA и майкрософтовский COM — довольно плохо проработанные технологии для связывания разнородных систем.

    Не скажу за CORBA, но есть ли у Вас конкретные претензии к COM?

    А COM имеет довольно узкое применение для связи программ в среде MS Windows, хотя никто не мешал его с самого начала разработать более универсальным.

    «Узкое применение»? Да он в Windows ВЕЗДЕ. То есть вообще везде. Что же до «универсальности» — прошу пояснить свою мысль. Это Вы о кроссплатформенности? Или о том, что какие то интерфейсы невыразимы на MIDL?

    В мире Unix, для взаимодействия консольных программ есть технология каналов (pipe), о которой я уже писал раньше.

    Вот как раз это следовало приводить в качестве отрицательного примера ВООБЩЕ не проработанной технологии для связывания разнородных систем. Ну то есть ее могло хватать для задач тридцатилетней давности, но сейчас — однозначно нет.

    Майкрософт, например, в своей реализации пайпов в powershell добавила объектность, что потенциально должно было сделать их супергибкими. Но простые решения, как говорится, «рулят».

    Что значит «потенциально»? Вообще то, если взять пример из Вашей первой статьи, то на PS все будет именно так, как я описал:

    ps | where {$_.Name -match «powershel+»} | kill

    Естественно есть сокращения для часто используемых вещей типа «kill -n powershe*», но это уже абстракция более высокого уровня, созданная исключительно для удобства (программист может и сам вводить эти абстракции, если они ему нужны)

    И где сейчас этот powershell…

    Что Вы хотите сказать? Даже если брать только Windows 7, в которой он по дефолту, то установлено уже почти 200 миллионов копий — в несколько раз больше, чем всех установок Linux, MacOSX, SUA/Windows и всяких древних коммерческих юниксов.
    • 0
      1. К COM претензии только в одном — за рамки мира windows он не выходит. Внутри windows вполне себе технология. Я cobra ругаю, а не com.

      2. Про узкое применение — я имел ввиду для межпрограммного взаимодействия в однородной майкрософтовской среде. Например, свою почтовую службу, работающую на юниксе, я по COM Ник чему не подключу. А по SOAP, например, вполне. Хотя, конечно, это не совсем сравниваемые вещи.

      3. Юниксовое связывание используется на несколько порядков активнее, чем виндовое COM. Потому что его используют не только 'родные' компонеты ОС, но и 90% программ на sourceforge. Поэтому с windows powershell сравнивать плохо.

      У нас тут был великолепный опыт разработки на windows script engine. я сейчас с айпада пишу — неудобно, если Макс вылезет, буду ему признателен за примеры. Это вообще чудо какое-то, а не инструмент. Хотя не совсем в тему.

      • 0
        Блин, он corba на cobra переправил
      • 0
        1. Не могу вспомнить ни одной Windows-specific части в COM. Более того, есть успешные реализации типа COMsource или даже так. Если смотреть на неполные реализации COM, то все становится еще интереснее. Под прицелом оказываются не только carbon/cocoa, но и I/O Kit (да, у некоторых даже драйверы ядра частично на COM).

        2. Дык COM как таковой здесь ни при чем. Более того, «довольно плохо проработанные технологии для связывания разнородных систем» к этой претензии не относится ну совсем. То есть вообще. Более того, тот же XPCOM довольно точно повторяет собственно дизайн COM, но ABM требует, чтоб IUnknown был переименован в nsISupports. Ну а w3c «на полных парах» разрабатывает WebIDL. Глядишь лет через 10-15 (когда у всех уже будут собственные «нестандартные» реализации) и примут.

        3. Вообще то, виндовое компонентное связывание используется на несколько порядков шире, чем plain-text пайпы. Хотя бы потому, что оно проникло далеко за пределы винды.

        Windows script Host, Вы имели в виду? Отличная штука, да. До сих пор частенько пользуюсь — чисто по привычке.
      • +1
        Ага. Уникальный опыт с Windows script Host у нас имеется.

        По просбе Рауфа распишу поподробнее.

        Писали мы инсталятор для XP.

        Инсталятор этот должен был снести MySQL, Adobe Air и nCron из состава старой софтины, затем установить наш новый софт состоящий из Apache,PHP,nCron,Chromium-portable, fonts, images и собственно PHP-приложения.

        Стандартные install-генераторы нам не подходили, ибо установка должна была проходить в один клик и были специфические вещи, с которыми стандартный генератор не справится.

        Итак задача полностью:
        Запуск из-под админа.
        Снести службу MySql
        Снести службу nCron
        Установить консольный zip.exe
        Распаковать части нового ПО и раскидать по своим местам
        Дать права на часть новых файлов в системе непривелегированному пользователю some_user
        Зарегистрировать службу Apache и прописать ей авто-старт
        Зарегистрировать службу Cron и прописать ей авто-старт
        Прописать в PATH пути до hg.exe и php.exe, чтоб потом не мучаться
        Пользователю some_user в автостарт прописать вместо explorer.exe (ну там уже не explorer, а Air приложение) Chromium в полноэкранном режиме.
        Забрать с сервера данные
        Сменить разрешение экрана
        Перезагрузиться, чтобы приложение стартовало при загрузке.

        Мне как, пользователю Linux на своей системе нацарапать такой инсталятор на Bash — полчаса.
        Когда-то давно я помню игрался с Windows script Host, потому решил, что за полдня я этот инсталятор напишу.

        В итоге вышло ДВЕ НЕДЕЛИ на разработку инсталятора. И это при всем том, что мне постоянно помогал очень грамотный в WSH Windows-админ. (Спасибо, Дима!)

        Мы встретили много нелогичностей

        1. Где-то надо использовать двойные кавычки, а где-то одинарные.
        2. Чтобы запустить системную команду иногда нужно писать cmd /c command
        3. Как поменять права на папку рекурсивно скриптом, не проходя вручную по дереву не нашли, пришлось после создания пустой папки присваивать ей права и устанавливать атрибут наследования прав подкаталогами.
        4. Шрифты простым копирование в каталог Windows/fonts не устанавливаются. Нужно после этого открыть explorer.exe на этом каталоге, чтоб винда автоматом установила эти шрифты, ну или писать каждый фонт вручную в реестр.
        5. Ветки реестра пользователей назваются не по имени а по какому-то SID, чтобы его найти нужно сделать запрос (нечто типа SQL) к WMI (Windows Management Interface) и забрать этот SID по имени пользователя.
        6. Записать в чужую ветку даже из-под админа просто так не получится. Ветка не подгружена — надо залогинить пользователя в систему. Но как сделать это в скрипте??? Лучшего способа мы не нашли: стартанули службу планировщика задач, установили задание на calc.exe через полчаса, принудительно стартанули задание — Ура!!! Пользователь залогинен.
        7. Реестр вроде удобная вещь и все настройи системы должны храниться там, но вот беда — с разрешением экрана какая-то Ж… Там столько всего нужно поменять… Пришлось взять какую-то консольную программку — qres.exe.
        8. В дополнение ко всему такие вещи как запись пользователю в реестр, исполнение qres.exe работают нестабильно, потому приходится проверять результат и повторять операцию.

        9. ага, вот еще вспомнил — в параметрах комманды sc (Service Control) есть параметр старт… Так вот мы долго ржали, когда поняли, что start=auto не работает, но работает start= auto (с пробелом — это должны быть разные argv[ ] ) :) ( чтобы выключить компьютер нажмите кнопку «пуск» — Где логика???)

        Вкусный опыт правда? После этого я уже не говорю, что Windows простая или плохая система. Для меня не подходит — да! Но теперь я знаю, что она гораздо сложнее *nix в тех местах, где эта сложность не нужна. Я уверен, что Windows нужно просто знать, и еще больше уверен, что людей, действительно знающих Windows очень не много! На моем пути был только один (все тот же Дима).

        Мои выводы: под Windows писать софт я постараюсь не браться. Если нужно просто, быстро, стабильно и предсказуемо — Выбирайте *nix. Unix way is my way.
  • 0
    CORBA вроде как ооочень в яндексе любят кстати.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.