9.2.Стандарты разработки

В проектной команде разработчики должны соблюдать лучшие практики (best practices) и стандарты разработки, применяемые для платформы и конфигурации ERP-системы. Это позволяет делать код единообразным, обезличенным (без авторских стилистических особенностей), читабельным для любого другого разработчика, совместимым с исходным кодом ERP-системы. Соблюдение стандартов может требовать дополнительных усилий от разработчиков, т. к. «быстрый» код без соблюдения стандартов тоже может работать, но его масштабируемость и отчуждаемость для передачи другим разработчикам (команде поддержки со стороны заказчика) может быть низкой.

Система стандартов и методик разработки конфигураций для платформы «1С:Предприятие 8» () – это свод правил, позволяющий разработчику избежать многих возможных проблем на этапе разработки и поддержки прикладного решения. Описание стандартов является частью официальной документации по информационно-технологическому сопровождению «1С:Предприятия». Рекомендуется следовать стандартам при доработке 1С:ERP в проектах внедрения системы автоматизации.

Требование соблюдения стандартов разработки и правила именования проектных метаданных (для отделения их от штатной функциональности системы) можно прописать в уставе проекта. Руководитель проекта со стороны заказчика особенно заинтересован в этом пункте, т. к. ему потом обеспечивать дальнейшее обслуживание системы (возможно, силами других подрядчиков), а для этого код в ней должен быть «правильным».

Фирма «1С» предоставляет и постоянно развивает необходимую информацию по разработке и администрированию конфигураций на платформе «1С:Предприятие 8»:

• книги и стандарты по разработке и администрированию –;
• технологические вопросы крупных внедрений –;
• блог разработчиков платформы «1С» – ;
• ютуб-канал платформы «1С» – «1C Platform» ;
• курсы и экзамены – .

При разработке новой функциональности нужно помнить о так называемом «техническом долге» – когда код пишется неоптимально, задачу свою решает, но производительность или последующая масштабируемость (возможность развития и доработки) низкие. В качестве примера можно привести какой-нибудь алгоритм, который обрабатывает данные системы на протяжении часа, тогда как после оптимизации время работы может сократиться на порядок – до 5–7 минут. Есть разница? Для конечного пользователя точно есть. Некоторые неоптимальные алгоритмы создают нагрузку на всю систему, мешая работе других пользователей, а результат работы алгоритма оперативным не назвать: он может быть доступен через несколько часов или только на следующий день.

Отправить