Работает в Москве, женат, двое детей. Интервью брал Евгений Каратаев.ЕК. Привет. Дай мне интервью по асе? Мне интересно сделать серию интервью среди технарей, занимающихся или раньше работавшими с М.
АД. И куда ты его? На сайт?
ЕК. Да.
АД. Ну, на, бери...
ЕК. Как ты первый раз познакомился с М-системами?
АД. Директивно. Пришёл начальник, сказал: "Будем писать на вот этом". А мне было пополам.
ЕК. Какая реализация М была выбрана, что это был за проект?
АД. Это была разработка корпоративной управленческой учётной системы для торговли. Реализация - последний OpenM, не помню, какой он там был по номеру. Реальная инсталляция осуществлялась уже на cache' 2.
ЕК. На каких машинах работал сервер каше?
АД. В каком смысле? На писюках, конечно. Кажется, первый сервер у клиента был пень второй, памяти 512, под NTёй. Под датасет тогда нам выдали ажно 500 М, без возможности автоинкремента размера. И что? При достаточно солидном объёме данных, производимых пользователями (крупная торговая фирма, всё-таки), я стал испытывать неудобства только года через 3. Тогда мне его щедро увеличили до гигабайта, и я про него забыл до самого конца.
ЕК. Какие средства разработки использовались, по какой схеме строилось приложение?
АД. Средства - исключительно кашовые. Приложение делалось на классическом M (диалект InterSystems, с list'ами), но в объектной идеологии. Т.е., фактически, была реализована объектная работа без объектного синтаксиса. В работе самого приложения была реализована академически чистая схема WorkFlow. Технологически при разработке пользовались контролем версий PVCS и их же трекером задач (ныне Merant, - прим. ЕК.).
ЕК. Сколько человек участвовало в разработке, каково было распределение ролей?
АД. 5 челов. Один - интерфейсные средства (клиент), один - система поддержки клиент-серверной связи и системные функции cache', двое прикладников, ещё один не помню, чем занимался. Но что-то полезное делал. Ну, и ещё начальник 6-м.
ЕК. Какие проблемы решались самостоятельно, какие решения использовались готовыми?
АД. Фактически, всё было разработано с нуля. Ну, с учётом предыдущего жизненного опыта. Тем более, что среда была, собственно, новой для всех. Самой главной (первой) проблемой при разработке было отсутствие внятного клиента. Средств работы с web-страницами у InterSystems тогда не было, нормального коннекта к, скажем, Delphy, тоже. Большая часть М-разработок на тот момент была реализована через терминал (вообще, очень пассивна позиция InterSystems в отношении клиентских средств). В результате был реализован собственный оконный клиент для Widows, позволяющий писать обработку контролов прямо на М.
Ещё при разработке сознательно ушли от "строковой" направленности M при работе с объектами БД, перейдя исключительно на целочисленную идентификацию. Ну, и, естественно, как-то решались традиционные транзакционные проблемы БД: одновременное редактирование записей, контроль уникальности записей справочников, удаление записей, целостность операций (отмечу, что тогда у InterSystems уже появились транзакционные операции, которых, по воспоминаниям ветеранов, до того не было. Как жил народ, вообще не представляю).
Кстати, многие вещи были решены легко и изящно: правами доступа. По возможности пользователям запрещалось вообще всё, а что не всё, то разрешалось только избранным. Из известных мне внедрений чуть ли не единственный случай, где поддержка и сопровождение БД осуществлялись комплексом программных и АДМИНИСТРАТИВНЫХ методов (у заказчика).
ЕК. Как организовывалось тестирование проекта?
АД. Если говорить о стадии разработки, то, после разработки базовых библиотек, которые тестировались всесторонне, но однократно, практиковалось "сдаточное", а затем "приёмочное" тестирование. Делалось всё объектно-модульно, так что объём конкретных тестов при переделках был невелик. Это что касается бизнес-логики. Что касается клиента (кстати, написанного уважаемым Евгением Каратаевым), то при каждом его изменении он гонялся прикладниками по полной программе, чтоб мало не казалось.
ЕК. Какая дисциплина обработки ошибок была принята в проекте?
АД. Что касается ошибок, которые могли возникать при эксплуатации, то прямо в БД создавался протокол на основе ETRAP, который сохранял полный контекст по всем уровням стека. Если программист обнаруживал такое, то он пытался выяснить у запротоколированныъх пользователей, при каких условиях они добились такого результата.
Кстати, именно там я впервые обнаружил ошибки, не имеющие отношения к кодированию (программно корректное искажение целостности бизнес-логики). Т.е., уровня проектирования. Тут уж ничего не поделаешь, приходилось после ликвидации их разрабатывать средства, которые восстанавливали смысловую целостность данных с какого-то момента.
ЕК. Какие технологические возможности каше использовались?
АД. Ну, введённые, как я уже сказал, незадолго до этого транзакционные операторы; штатное локирование с постусловным таймаутом; очень широко - list'ы имени InterSystems; это при программирования логики. Кроме того, для клиент-серверной работы использовался TCP-доступ. Кстати, глубоко потом это позволило даже работать собственным клиентом через интернет, на выделенный адрес. Очень медленно, но уверенно :).
ЕК. Этот проект в настоящее время в каком состоянии?
АД. Как говорили знающие люди, жил он долго и счастливо, и пользователи даже были довольны, насколько могут быть довольны пользователи. И его остатки, кажется, до сих пор работают. Было несколько аналогичных внедрений (следующего поколения), но уже без меня. К сожалению, серьёзного коммерческого развития это направление не получило и постепенно стало сворачиваться по административно-деловым причинам.
Кстати, отличительной чертой проекта были весьма обширные справочники. Как потом выяснилось, они давали хорошую фору даже аптечно-фармацевтическим. Только при первичном вводе было заведено порядка 200 000 записей. Вот, там, где они применялись, он и работал дольше всего (возможно, доныне). При этом скорость была вполне приемлемая.
ЕК. Какие технически красивые решения ты мог бы отметить в этом проекте?
АД. Повторюсь: красив был клиент. Тупой, правда, неимоверно, по возможностям. Но всё, что надо для жизни, было. И описывать его прямо в мампсе... Мечта. Механизм связи с сервером был хорош, имея некоторые недокументированные возможности, которые интерсистемс просил никому не говорить... :-) А остальное - да просто код был хорошего качества. Тогда мы ещё ввели версионное хранение учётных документов, с возможностью отмотать назад. Кажется, на базаре такого не было. Потом, сам подход WorkFlow обычно хвалят перед заказчиком, но он, в первую очередь, очень удобен для программистов. В частности, права доступа к данным для пользователей - да одним пальцем. Если вспомнить, когда это было сделано, и когда "бизнес-процессы" появились, скажем, в 1С...
ЕК. В каком проекте ты участвовал потом?
АД. А потом сопровождал в аутсорсинге одну крупную медицинскую систему. Правда, не сказал бы, что очень хорошо получается. Коротко - большая сложность, много крупных клиентов. Web-интерфейс через csp. Правда, все заложенные в csp возможности не используются, очень много JavaScript'а. Система унаследована с очень давних времён, и доразвивалась в процессе. Наследие mainframe'ов видно невооружённым глазом. Одновременно используются объектный (как основной), sql и прямой доступ. Выборки практически все через sql. Но, в результате такого развития, много параллельных кодов (со сходной функциональностью), очень сложно воспринимать реализованную логику.
Одна интересная техническая особенность: динамическое хранение клиентских объектов. Т.е., все классы, отвечающие за логику, лежат на сервере. А содержательные объекты описаны на сервере, а лежат во внешних датасетах (определённых, как отдельные неймспейсы). И, в зависимости от информации при логине пользователя, подключается тот или иной датасет с клиентскими записями.
ЕК. Кто участвует в разработке?
АД. Собственно программисты заказчика и аутсорсеры.
ЕК. Что бы ты хотел видеть в новых версиях каше?
АД. Я давно свыкся с развитием каше от классического мампса. Поэтому есть у меня одна заветная детская мечта. Возможность задания порядка обработки индексов в запросе, а самое лучшее - возможность указания полного механизма построения запроса. При сохранении sql-обвязки.
И ещё того, о чём давно говорит всё прогрессивное человечество: возможности навигации по запросу назад (без его сохранения).
ЕК. Как активно ты пользуешься техподдержкой Интерсистемс? Какие проблемы были решены?
АД. Давненько не брал я в руки шашки. Несколько лет не пользуюсь вообще. Но, по воспоминаниям, ничего плохого сказать не могу. Сравнивая с отзывами коллег о других службах поддержки, нахожу, что она, видимо, из лучших. Помнится, меня даже в головном офисе на карандаш брали, и ответили, и ответили внятно, и достаточно оперативно. Жаль, конечно, что ушёл Тимур Сафин. Кстати, и документация тоже из лучших (если раньше настольной книгой был Кирстен, то теперь его смело можно выбросить).
ЕК. Спасибо за интервью.
АД. Да не за что.
Комментариев нет:
Отправить комментарий