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

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

Соискателям мы предлагали решить относительно несложное тестовое задание, в котором нужно было немного доработать простой пример. Некоторые люди справились, но от многих пришли гневные письма с возмущением вроде: “Вы ищите программиста или бизнес аналитика ?”.

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

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

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

Статей с критикой 1С на Хабре достаточно (например, один, два, три), но, на мой взгляд, они либо слишком много внимания уделяют всяким мелочам, вроде неправильной организации меню, либо рассуждают о слишком абстрактных вещах, в которых 1С, возможно, и не виноват. В этой же статье, как и в статье про SQL, речь пойдет исключительно о фундаментальных (и вполне осязаемых) проблемах, которые касаются всех и каждого, кто разрабатывает / дорабатывает решения на 1С, и приводят либо к существенному росту порога вхождения, либо к серьезному падению производительности, либо к значительным трудозатратам со стороны разработчика.

В различных приложениях регулярно возникает задача по поддержке логики изменения во времени некоторого атрибута объекта относительно некоторого субъекта (или субъектов). Например, это может быть изменение розничной цены товара в магазинах или показателей KPI для сотрудников.

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

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

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

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