Доработать за 60 секунд

Вы знали что возможно доработать под вас и ваши задачи практически любой современный софт? Без исходников, без примеров, без API и документации и без «благословения автора» — оно все равно будет работать для вас, на вас и так как вы хотите.

Такие доработки — одна из моих уникальных услуг, поэтому рассказываю как это происходит, на реальных примерах.

О чем речь

Допустим, вы купили какой-то закрытый софт для компании — ERP/CRM, биллинг, какую-то аналитическую или расчетную систему или что-то еще более редкое и специфичное для вашего бизнеса, описываемая одной фразой:

После начального периода эксплуатации, стало понятно что нужны доработки — часто бывает что нужна какая-то мелкая херня (с технической точки зрения), но нужна она именно в строго определенном месте интерфейса чужой системы.

Классический пример:

есть огромная форма с данными, которые по кнопке должны улетать куда-то еще (в другую систему, в отчет, в выгрузку на диск), а кнопки этой нет.

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

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

Вопрос легальности

Очевидно что первый же вопрос, который вы мысленно себе задали увидев начало статьи: а не ох#ел-ли автор такое предлагать?

Это же прямое нарушение условий лицензирования и законов о интеллектуальной собственности.

Спешу вас успокоить:

Или не делаете это с портретом президента.

Если проще, то мировая практика не запрещает «in-house» доработки софта, если только вы не начнете их продавать как продукт, либо продавать доработанную версию под видом своего продукта.

Такая практика существует в Европе, в Азии и в Африке, помимо очевидной РФ.

Единственное исключение — США, со своей атмосферой в патентном праве и лицензиях на ПО, но думаю если уж вы полезли работать в США то мои советы вам точно не нужны.

Максимально возможную проблему, которую вы получите после вот такой кастомизации чужого софта — отказ от гарантийных обязательств.

И то далеко не всегда.

А поскольку часто от закрытого софта зависит работа компании и сам бизнес — думаю что риски вполне приемлимые.

Так как это все происходит и что вообще можно сделать.

Технические возможности

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

Тем не менее, наш опыт показывает, что:

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

Плюс распространение веб-технологий, где есть явное отделение рендера (браузера) от технологий передачи (прокси, API Gateway) и серверной стороны — все это позволяет встраивание и кастомизацию потока данных по-умолчанию.

Кстати, скрытых или явных способов кастомизации стало настолько много, что большая часть доработок происходит как раз через них, без применения какого-то серьезного реверс-инжиниринга.

Ниже на конкретных примерах и технологиях я расскажу о таких доработках. Начнем с классики.

Десктоп и утилиты

Чаще всего речь про софт для Windows, реже — Mac или про что-то совсем редкое или сделанное на заказ, но с утерянными или сильно устаревшими исходниками.

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

Но в корпоративном сегменте (если однотипное ПО нужно поставить и эксплуатировать на 500-1000 машин) все всегда было несколько проще, поскольку мы ориентируемся в основном на этот сегмент — речь как раз про корпоратов и их проблемы.

Что важно отметить:

Чаще всего запросы на доработку касаются офисного ПО от Microsoft либо расширений браузера Chrome (реже Firefox) — все эти штуки имеют обширный инструментарий для разработчика и позволяют глубокую кастомизацию штатными средствами (т.е. без потери гарантии от производителя).

Но, даже если речь идет про кастомную разработку или редкий и закрытый софт — в 99% случаях его возможно доработать в том или ином виде:

1. Любые программы на «managed» языках вроде Java/.NET поддаются кастомизации и доработкам практически всегда без особых проблем. Их ключевые графические фреймворки (Swing/WPF) имеют массу способов добавить необходимый визуальный функционал.
2. Большая часть программ на Си/C++ поддается реверс-инжинирингу и восстановлению до исходных кодов, что в дальнейшем позволяет создать свою сборку ПО с необходимыми функциями.

Да, бывают исключения:

однажды я в рамках заказа, наткнулся на специальное ПО для обслуживания спецтехники от известного немецкого концерна (база деталей с описанием), которая хоть и была реализована на Java-технологиях, но использовала специальную реализацию JVM, c серьезной защитой от взлома.

Поэтому 100% гарантий нет и всегда происходит предварительное изучение вопроса, до начала процесса доработки.

Оффлайн системы с веб-интерфейсом

Хорошие примеры таких систем с точки зрения пользователя:

Atlassian JIRA, Microsoft Dynamics, SAP R/3, Oracle Siebel и так далее.

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

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

Кастомный софт — реализованный на заказ для вас кем-то другим, либо серийный но редкий, с небольшим количеством клиентов и без возможностей доработки штатными средствами (SDK просто нет).

Вот хороший пример интеграции с таким кастомным ПО:

В примере выше был реализован отдельный вебсервис, отдающий специальный виджет, который через iframe встраивался в чужое приложение.

Доработка внешнего ПО в данном случае заключалась в добавлении вкладки с Webview, отображающим этот самый виджет внутри.

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

Это было в 2011 году, 12 лет назад.

На сегодняшний день мы стали сильно умнее, сильнее и можем куда больше. Пишите.

Онлайн сервисы

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

Всем понятно что это искусственные ограничения, обсусловленные ничем бюрократией, повесточкой или текущей политической обстановкой.

Но жизнь идет своим чередом и нужно продолжать работать, поэтому если вы например вдруг заходите открыть свою Додо-Пиццу в Лондоне или Париже и нужно будет реализовать выбор адреса доставки — пишите.

Мы одни из немногих кто знает как получить аналог ФИАС в границах туманного альбиона или родины вина, проституции и революций.

Вот хороший пример такой интеграции:

Что хотелось бы отметить в этом решении:

1. Владелец сервиса Infogreffe (а это крупная полу-государственная компания во Франции) не был в курсе подобной интергации в каком-то мелком стартапе;
2. Реализовано все было через специальный проксирующий сервис, с переписыванием контента (в первую очередь прямых ссылок) на ходу, в том числе в отдаваемом JavaScript коде;
3. Реализация позволяла конечным пользователям сервиса нашего клиента оплачивать дополнительные услуги и документы Infogreffe на стороне сервиса.

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

Сами данные вполне себе открытые и публичные, но за автоматизированный доступ через API либо в выгрузках — компания берет очень немаленькую плату, неподъемную для стартапа.

Так что встречается такое часто.

Открытое ПО

Третий популярный вариант доработок — кастомные сборки открытого ПО. Главная сложность тут уже в другом: оно все большое.

Стандартная сборка какого-нибудь LibreOffice из исходников занимает 4-6 часов даже на мощном современном компьютере.

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

Чаще всего встречаются задачи, связанные с Eclipse RCP, это такой движок для сред разработки, очень популярный.

Поэтому остановлюсь на нем подробнее, в качестве иллюстрации такого рода работ.

Очень много коммерческих решений по проектированию, схемотехнике, автоматизации, аналитике и так далее сделаны на базе этой платформы.

Один из примеров такого ПО, которое я регулярно использую это Wireframe Sketcher:

WireframeSketcher — такое мощное настольное приложение для прототипирования графических интерфейсов.

Само приложение является закрытым и платным, использует триальный период и просит активацию, но построено на полностью открытом движке Eclipse.

И таких решений много, это достаточно популярный способ сделать хороший коммерческий софт.

Еще одним хорошим примером ПО на базе Eclipse RCP является DBeaver:

Это наверное один из самых популярных DBMS приложений, которые сейчас активно используются и развиваются.

Используется для доступа к базам данных и написания SQL-скриптов и запросов, в том числе нашей командой.

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

Что нужно знать про Eclipse RCP:

1. Весь функционал конечного приложения реализуется в виде набора плагинов (с зависимостями), которые специальным образом собираются и подкладываются в сборку;
2. Существует вариант дистрибьюции вашего приложения не в виде отдельной сборки а в виде устанавливаемых плагинов, публикуемых в каталоге приложений Eclipse;
3. Сам Eclipse построен на базе графического фреймворка SWT, который является нативным, поэтому сборки самого Eclipse также являются нативными и привязываются к конкретной платформе: Windows, Mac, Linux и так далее.
4. У Eclipse RCP все плохо с обратной совместимостью, поэтому всю цепочку от версии SWT, версии Eclipse и до конечных плагинов нужно холить и лелеять, поскольку обновление даже минорной версии все легко ломает.

Зная в деталях как весь этот цирк устроен и имея практический опыт — мы вполне можем (и делаем) доработки такого ПО на базе Eclipse RCP.

Редкие варианты

Помимо описанного, были много интересных но разовых случаев доработок, поэтому кратко:

• Доработка Bugzilla (Perl)- отдельный статус и интеграция с внешним сервисом;
• Доработка Rhodecode (Python) - дополнительные пуши и хуки;
• Плагин для Microsoft Outlook — дополнительные кнопки в интерфейсе, с логикой;
• Плагины для Jira — сводные отчеты, дополнительные кнопки;
• Плагин для BPMOnline — интеграция с отдельным СМС-шлюзом;
• Плагин для Unity Engine — настройка и использование прокси при вызовах вебсервисов;

И еще много всякого интересного.

Насколько все это разумно

В принципе, любая разработка должна начинаться осознанно, с четкой потребности в этом и хотя-бы несколькими попытками обойтись подручными средствами и простой автоматизацией.

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