Рекоменданции

1. Придерживаться Coding Standards and Naming Conventions . В глаза бросается много

переменных с нижним подчеркиванием

Также видел асинхронный метод, есть рекомендация от Microsoft использовать в конце

название суффикс Async

2. Следовать принципу единственной ответственности (SRP). Как я увидел у тебя сборка состоит из
несколько файлов, внутри которых навалено кучей разных по ответственности классов/методов,
при чем некоторые копи-пастом повторяются (а можно было использовать повторно один и тот
же). В качестве примера, я перерефакторил твою сборку UDS.QuoteProductCaldic2 (в лс сброшу),
чтобы наглядно показать, как правильно использовать данный принцип. На картинке видно, как
поменялось древо проекта
Такой подход упрощает дальнейшие модификации, так как проще разобраться в одном блоке
функциональности, нежели распутывать сложные взаимосвязи. Также при модификации логики в
одном месте приложения снижаются риски возникновения проблем в других «неожиданных» его
местах. Это дает возможность повторного использования кода, так как сложные объекты с
комплексными зависимостями обычно очень сложно использовать повторно, особенно если
нужна только часть реализованного в них функционала. А небольшие классы с чётко очерченным
функционалом, напротив, проще использовать повторно, так как они не избыточные и редко тянут
за собой существенный объём зависимостей. Это можно наглядно увидеть в моем примере, такую
сборку будет намного проще расширять/модифицировать как самому так и другим
разработчикам, а некоторые модули без проблем переносить в другие сборки.

Есть видео на ютубе по этому принципу, а так же будет полезно ознакомится и с другими
принципами акронима SOLID.

3. Использование базовых классов. Полезная практика у нас на проекте использовать для СРМ
плагинов класс BasePlugin.cs (есть в примере). Это улучшает читаемость кода, поскольку плагины
реализуют метод Execute, но по коду не всегда понятно на какие степы они зарегистрированы и с
какими сущностями они работают и в таком случае приходится на каждый плагин лезть в СРМ
смотреть все это. Чтобы освободиться от этого, сделан такой «Декоратор» внутри которого
реализован метод Execute, и заготовлена коллекция которая связывает степы с нужными
методами и нужными сообщениями. Заполняется она внутри конструктора наследников. Очень
удобно открыв плагин и посмотрел в конструктор, сразу стает понятно к чему он относится
4. Использование enum для значений опшн сетов. Повышает читаемость кода

5. Ознакомится с методами, которые есть в System.Linq. Много действий можно упростить

написав выражение в одну строчку. К примеру для коллекции вместо написания метода
IsListContainsEntity() можно было использовать Any()

Рекомендации по JS

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