Петр Волынский: «Программирование – это наука, в которой нет рутины, а, наоборот, постоянные вызовы»

Петр Волынский:
«Программирование – это наука, в которой нет рутины, а, наоборот, постоянные вызовы»

На вопросы «СА» отвечает Петр Волынский, технический директор Comindware

Петр Волынский – технический директор Comindware. В 2004 году закончил МИФИ. Увлекаться программированием начал еще в школе. В 2005-м пришел в Acronis Junior-разработчиком, далее стал Team Lead, руководителем отдела управления продукцией, а затем руководителем направления (в том числе линейкой True Image Home). В конце 2009 году перешел на должность руководителя направления консумерских проектов в «Лабораторию Касперского». В настоящее время руководит разработкой программных решений компании Comindware

– Чем вы занимаетесь в Comindware?

– Я являюсь сооснователем Comindware и в компании совмещаю две роли одновременно – CTO (технический директор) и VP of Engineering. В роли VP of Engineering я полностью отвечаю за организацию производства программного обеспечения, от планирования до стратегии разработки. А СТО – это техническая экспертиза, включающая стратегию и тактику разработки, выбор платформ, составление технологической дорожной карты, а также формирование общей стратегии компании.

– С чего все начиналось?

– Я начал программировать еще в школе на BASIC, продолжил в институте, а потом стал заниматься этим серьезно, когда попал в Acronis, где за несколько лет вырос от Junior-разработчика до руководителя направления продуктовой разработки.

Программировать интересно именно потому, что это дает тебе возможность быть частью ИТ. А это новые горизонты и совершенно новые возможности. Програм-мирование – это в своем роде определенная наука, в которой нет рутины, а, наоборот, постоянные вызовы, когда за минимальное время нужно создать универсальные и гибкие решения или продукты.

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

– Какие технологии (программная архитектура) используются в Comindware?

– В Comindware используется четырехзвенная архитектура.

У нас есть своя запатентованная технология управления данными Elastic Data (графовая база данных). Изначально, когда мы проектировали платформу, мы хотели сделать ее гибкой, менять данные на лету, добавлять любое количество связей, делать любые новые интерпретации и т.д. Такую гибкость могла обеспечить нам только графовая база.

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

Далее – различные модули, которые используют наш ИТ-фреймворк и благодаря которым наши клиенты могут создать точно такой же модуль (мы изначально пишем платформу, которую наши клиенты могут расширять на всех уровнях).

– В чем особенности Elastic Data?

– Elastic Data – это целый стек технологий, завернутый вокруг графовой базы данных.

Собственно, стек – это как на рис. 1, но он еще дополнительно расширенный нами.

Рисунок 1. Стек технологий, взято с http://www.dbis.cs.uni-frankfurt.de/~tolle/RDF/index.html

Итак, по порядку. Снизу графовая база, посередине собственные онтологии и особенности наподобие расширения языка правил или регистрируемые extensions для запросов.

Можно задаться вопросом: а собственно, зачем нужна эта Elastic Data? Причин довольно много:

• Обеспечение абсолютной гибкости в моделировании и изменении модели данных на лету – без перестройки таблиц/связей.
• Обеспечение горизонтального масштабирования за счет того, что все объекты в системе имеют уникальный идентификатор.
• Одновременная и нативная поддержка шардинга – две базы данных и связанные с ними бизнес-приложения могут содержать знания о разных аспектах одного объекта. При этом третье приложение может брать данные из двух первых баз и нативно склеивать данные.
• Готовая онтология – система описания классов методов объектов, системных и пользовательских.
• Дополнительный встроенный движок логического вывода, который позволяет нативно строить любое количество views на графовые данные и обладает собственным кэшем.
• Встроенный движок бизнес-правил, работающий on demand, то есть всегда в режиме реального времени можно получить результаты сложных бизнес-правил.
• Нативная возможность расширения на уровне бизнес-правил – например, какое-то свойство объекта может не храниться в базе, а вычисляется на лету с использованием внешних систем, причем для человека или сервиса, выполняющего запрос к базе из приложения, это прозрачно.
• Нативная возможность аддитивно расширять любые объекты любыми свойствами в необходимых аспектах: например, задача – это и объект на диаграмме данных, и элемент списка, и главный топик для дерева комментариев, и т.д.

– Какова в ней структура графа?

– Содержимое базы фактически состоит из нескольких частей:

• Данные об узлах и ребрах графа, проиндексированные специальным образом.
• Дополнительные метаданные, например, такие как inversePredicate – это когда прямой предикат (Юля сын Миша), а обратный – это Миша мама Юля, Юля и Миша – это узлы графа, а мама и сын – ребра или предикаты – такие вещи тоже нативно поддержаны в базе.
• Дополнительные таблицы с текстовыми данными, т.е. сами узлы – это спецхеш, а вот текстовые репрезентации некоторых узлов лежат отдельно (например, узлом может быть глава романа Льва Толстого, соответственно, конечно, неона является внутри базы узлом, а лишь ее идентификатор, содержимое лежит отдельно).

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

– Чтобы вы отнесли к минусам графовых баз данных?

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

• Сложность управления доступом к данным (security).
• Сложность сериализации и десериализации списков объектов.
• Сложность проверки логической целостности данных по сравнению с реляционными таблицами.

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

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

– Какую СУБД используете для управления графовой базой данных?

– СУБД написана в Comindware и основана на коде из SQLite библиотеки, наша СУБД поддерживает ACID-транзакции (https://ru.wikipedia.org/wiki/ACID). Писать мы ее начали потому, что на момент начала работ ничего подходящего в вебе не было, только через некоторое время появилось несколько графовых баз, но до сих пор далеко не все они поддерживают ACID, а для бизнес-приложений это просто необходимо.

– Как организован процесс интеграции с внешними сервисами? С какими?

– Comindware Business Application Platform предназначена в первую очередь для создания гибких бизнес-приложений для внешних и внутренних пользователей, для тех – весьма частых – случаев, когда существующие out of box-системы недостаточно гибки/открыты/и т.п. Как результат, то, с какими системами клиентам нужно будет интегрировать приложения на Comindware Business Application Platform, заранее определить невозможно.

Поэтому цель Comindware – предоставить максимально открытые, современные и гибкие средства интеграции, которые бы позволили покрыть все возможные сценарии работы с другими системами. Это достигается за счет двух вещей.

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

Второе – архитектура платформы разработана с учетом современных подходов, таких как BoundedContext, Domain-Driven Design, Microservices, и нативно их поддерживает. Из интеграций с распространенными системами можно выделить Outlook, Sharepoint, ODATA, SalesForce, 1C, Jira.

– Что считаете своим новаторством в процессе разработки? Идеи, методологии, управление, программные решения или другое?

– В Comindware объединенный подход к методологии, мы одновременно работаем в методологии Agile, но также у нас есть дорожная карта на несколько кварталов вперед. В качестве управления у нас структура как матричная, так ипроектная, то есть, с одной стороны, есть общая стратегия, с другой – пожелания и возможность подстраиваться под определенные требования клиентов и заказчиков. Также у нас в компании прямая связь между customer support и нашими разработчиками, что позволяет нам «держать руку на пульсе».

– Каких методологий Agile (в соответствии с Agile Manifesto) придерживаетесь?

– Я постараюсь детально описать каждый из пунктов Agile Manifesto и как мы ему соответствуем.

• Люди и взаимодействие важнее процессов и инструментов: процессы и инструменты у нас есть, более того, мы используем решения Comindware для нашей внутренней работы. Но не всегда действия по процессу – наиболее быстрый способ достичь цели. Люди не должны сидеть исключительно в рамках тулов, в современном мире большинство людей привыкли общаться между собой через чаты, емейлы, но именно личное голосовое общение часто работает эффективнее и быстрее.
• Работающий продукт важнее исчерпывающей документации: мы часто делаем ранние версии продукта для наших партнеров и в общении с ними понимаем, как усовершенствовать и улучшить наш продукт. Таким образом, с одной стороны, у нас есть возможность собрать комментарии клиентов, а с другой – мы понимаем, какие вещи нужно лучше осветить в документации. Более того, когда мы работаем с конечным пользователем, мы готовим документацию уже с учетом запросов клиента.
• Сотрудничество с заказчиком важнее согласования условий контракта: мы придерживаемся модели Lean Startup, то есть мы стараемся как можно быстрее сделать качественный и рабочий прототип и отдать его заказчику. Мы пришли ктакой схеме работы, поскольку самые важные требования у клиента появляются в процессе эксплуатации. Также важно отметить, что первоначально у заказчика не всегда есть понимание, что ему надо, поэтому, когда клиент начинает работать с нашим прототипом, он лучше понимает, что именно он хочет.

– Готовность к изменениям важнее следования первоначальному плану?

– Мы в Comindware фокусируемся на том, чтобы наше решение не было set in stone, именно для того, чтобы наши заказчики и представители бизнеса могли визуализировать и менять процессы.

– В чем заключаются, на ваш взгялд, особенности процесса разработки?

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

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

Также у нас собственная внутренняя система, которая покрывает все наши процессы, релизы, обращение от клиентов и т.д. Особенность разработки в том, что наше решение поддерживает несколько языков, мы стараемся, чтобы переводы не отставали – своя локализационная база построена определенным образом.

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

Стоит отметить, что мы вовсю используем новые технологии для проектирования макетов (Zepplin) – очень удобные.

– Как появляются идеи? Что необходимо для того, чтобы начался процесс их практического воплощения?

– Идеи появляются из нескольких каналов, а именно:

• Клиентские кейсы.
• Взаимодействие с продукт-менеджерами.
• Общение с аналитиками и коллегами на различных мероприятиях.
• Brainstorm-сессии.

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

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

– Расскажите о новых технологиях Comindware. Что внедрили/применили/открыли нового?

– Наша новая версия Comindware Business Application Platform дает возможность для построения корпоративных программных решений для любых потребностей бизнеса. Платформа позволяет в минимальные сроки и с минимальными бюджетами решать задачи управления данными, процессами (BPMS), поручениями (ACM) и проектами, а также поддерживает мобильные устройства и облачную версию.

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

– Какой программный стек использован для разработки облачной платформы?

– Наше облако сейчас находится на серверах Amazon в нескольких регионах, соответственно, мы активно используем API Amazon для управления облаком.

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

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

– Какое программное обеспечение используете для работы (ОС, почтовый клиент, браузер, инструменты разработки и т.п.)?

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

У нас практически полностью автоматизирован Application Lifecycle Management (ALM). Мы изначально подходили к процессу разработки очень скрупулезно, что позволило и позволяет нам избегать большого количества ошибок. Например, с самого начала у нас был bug tracker (как только мы написали платформу, мы сразу же на ней сделали bug tracker), также существуют continuous integration и автодокументирование. Для планирования и ведения проектов мыиспользуем свой софт. В качестве messenger используются внутренние инструменты решений – Comindware Tracker и Comindware Project.

– Есть ли предпочтения к выбору аппаратной части?

– Наиболее удобная система – это Windows. Да, у нас есть и Мас и Linux, но на Windows у нас разработка на C#.

У меня есть Mac, но, с моей личной точки зрения, разработчику удобнее именно Windows-система, а для пользователя, наверное, Mac.

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

– Вы упомянули С#. Кроме него, какие еще используете языки программирования для разработки?

– Кроме С#, мы также используем С++ и C на уровне базы, JavaScript в большом количестве используется для браузерных клиентов, Objective C, Swift и Java для мобильных приложений. В то же время для работы с графом используется расширенный нами формат N3.

– Сейчас многие «уходят» в облака. А вам помогают сервисы в работе? А социальные сети?

– Социальные сети мне лично не помогают, только LinkedIn, который дает мне возможность «держаться» в тренде. И мы прекрасно понимаем актуальность облаков. Меня поражает, что то, для чего раньше требовался целый ИТ-департамент, теперь можно сделать одним кликом. Поскольку мы используем облачные платформы, накладные расходы на резервное копирование очень низкие, а выкатить обновление на одного клиента занимает меньше пяти минут.

Беседовал Игорь Штомпель

Комментарии могут оставлять только зарегистрированные пользователи