 |
|
|
|
Правильная доработка типовых решений от 1С. Разбираем кейсы легкой поддержки
Правильная доработка типовых решений от 1С Компания «1С» прочно закрепились в нише программ для автоматизации деятельности предприятий. «Бухгалтерия предприятия», «Управление торговлей», «Зарплата и управление персоналом» и т.д. стали визитными карточками компании и успешно применяются как на маленьких, так и на больших предприятиях «1С» совершенствует свои разработки, но всегда найдется клиент с задачами, не покрываемыми типовым функционалом. Вот тут в игру вступают сторонние разработчики с благой идеей доработать типовое решение в соответствии с пожеланиями клиента. К сожалению, не все доработки приносят долгую радость. Перелопаченные до неузнаваемости конфигурации – верный путь остаться без обновлений от поставщика. Почему так происходит? Проблема с профессионализмом сторонних разработчиков или несовершенство архитектуры решений типовых решений? На мой скромный взгляд, проблемы с обеих сторон: «1С» не сильно популяризирует правильные подходы к доработке типовых решений, а многочисленные разработчики предпочитают работать по старинке, не тратя время на изучение новых возможностей и чтение «нудной» документации. Проблема Перед тем как начать говорить о решениях, озвучим проблему. Типовые решения не могут выполнить все «хотелки» компании, и единственный способ их реализовать – обратиться ксторонним/своим разработчикам. Если «хотелка» затрагивает типовые механизмы (объекты, формы, алгоритмы), то конфигурация становится непригодной для автоматического обновления. Обновить ее можно, но делать это придется в ручном режиме, и есть все шансы что-нибудь поломать. В итоге клиент получает желаемый функционал, проблемы с обновлением изависимость от сторонних разработчиков (при отсутствии собственного отдела разработки). От того, как правильно он оформил решение задачи, будут зависеть возможность и стоимость последующих обновлений. Документирование, инструменты Не имеет значения, какую конфигурацию вы пытаетесь дорабатывать, первое, что необходимо освоить, – процесс документирования. Без этого все последующие советы не будут иметь должного эффекта. Все вносимые изменения в обязательном порядке должны фиксироваться в трекере/wiki/базе и т.д. Документация по внесенным изменениям должна дополнять информацию изхранилища конфигурации или другой системы контроля версии. Документация не должна писаться ради документации, документы должны своевременно обновляться. Если эта задача выполняется и разработчики/менеджеры работают с такими документами, то количество ошибок, возникающих в процессе актуализации версий конфигураций споставщиком, существенно сокращается. В реальности разработки решений под платформу 1С еще не сложилась полноценная культура разработки. Далеко не все разработчики применяют специализированные инструменты, упрощающие ревью кода, документирование и т.д. Хотите создавать более простые в поддержке и сопровождении решения? Начинайте знакомиться с практиками разработки, ориентированными на другие платформы. Многие из них вполне реально перетащить в 1С. Статью целиком читайте в журнале «Системный администратор», №1-2 за 2017 г. на страницах 63-69. PDF-версию данного номера можно приобрести в нашем магазине.
|
ИГОРЬ АНТОНОВ, руководитель отдела разработки ПО, страховая компания АО «ДальЖАСО», Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
