ну что ж, предлагаю в этом теме обсудить ситуации, когда возникает серьезная архитектурная задача, которую можно решить разными путями, и не очевидно, какой путь лучше, так как у каждого есть свои недостатки и преимущества.
начну с двух примеров, но в самом начале предлагаю немного "раскидать" варианты исходных ситуации, так как они влияют на решения.
А исходные варианты такие:
(1) либо это "продуктовая" разработка (в том числе с легким "допилом" на месте под конкретного кастомера) или это создания с нуля относительно "уникальных" приложений под конкретного заказчика;
(2) либо проект - это расширение стандартного функционала СРМ и иже с ним, или это никак не связанный с СРМ проект на базе форс.сом (хотя стандартный Эккаунт\Контакт может использоваться).
Вот те проблемы, которые я могу предложить для обсуждения:
(1) Process-centric App (как почти все на СФ): что используем для создания бизнес-логики: по-возможности используем поинт-энд-клик конфигурирование или все, все закладываем в код?
(2) Используем или не используем стандартные Эккаунт\Контакт в форс.сом приложениях? дело даже не в лицензии, а в том, что многие сущности можно отнести к категории Эккаунт, но не хочется все забивать их в стандартный Эккаунт, плодить бесконечные РТ для большого Орга...
ваши мысли, другие проблемные ситуации...
ну что ж, предлагаю в этом теме обсудить ситуации, когда возникает серьезная архитектурная задача, которую можно решить разными путями, и не очевидно, какой путь лучше, так как у каждого есть свои недостатки и преимущества. начну с двух примеров, но в самом начале предлагаю немного "раскидать" варианты исходных ситуации, так как они влияют на решения. А исходные варианты такие: (1) либо это "продуктовая" разработка (в том числе с легким "допилом" на месте под конкретного кастомера) или это создания с нуля относительно "уникальных" приложений под конкретного заказчика; (2) либо проект - это расширение стандартного функционала СРМ и иже с ним, или это никак не связанный с СРМ проект на базе форс.сом (хотя стандартный Эккаунт\Контакт может использоваться). Вот те проблемы, которые я могу предложить для обсуждения: (1) Process-centric App (как почти все на СФ): что используем для создания бизнес-логики: по-возможности используем поинт-энд-клик конфигурирование или все, все закладываем в код? (2) Используем или не используем стандартные Эккаунт\Контакт в форс.сом приложениях? дело даже не в лицензии, а в том, что многие сущности можно отнести к категории Эккаунт, но не хочется все забивать их в стандартный Эккаунт, плодить бесконечные РТ для большого Орга... ваши мысли, другие проблемные ситуации...
1. Везде по максимуму пытаюсь использовать поинт энд клик. Стоимость работы имплементора существенно ниже стоимости работы девелопера. В код уходят только те вещи, которые трудно реализовать иначе.
2. По максимуму использую стандартные объекты и количество РТ вообще не смущает.
3. Сейчас моя головная боль Процесс Билдер. Вещь вроде удобная, но еще не обкатанная и очень много проблем с тестами.
1. Везде по максимуму пытаюсь использовать поинт энд клик. Стоимость работы имплементора существенно ниже стоимости работы девелопера. В код уходят только те вещи, которые трудно реализовать иначе. 2. По максимуму использую стандартные объекты и количество РТ вообще не смущает. 3. Сейчас моя головная боль Процесс Билдер. Вещь вроде удобная, но еще не обкатанная и очень много проблем с тестами.
По максимуму использую стандартные/встроенные иструменты.
По максимуму использую стандартные/встроенные иструменты.
Поддерживаю
[quote="Gres"]По максимуму использую стандартные/встроенные иструменты.[/quote] Поддерживаю
По максимуму использую кастомные решения и без особой необходимости вообще стараюсь не касаться стандартного функционала.
Да, решение получается абсолютно не "поинт энд клик" зато все легко реализуется, кастомизируется и ни с чем не конфликтует. На первой конторе с одним пакетом построенным на стандартном функционале навидался таких костылей что больше не хочется с этим связываться.
По максимуму использую кастомные решения и без особой необходимости вообще стараюсь не касаться стандартного функционала. Да, решение получается абсолютно не "поинт энд клик" зато все легко реализуется, кастомизируется и ни с чем не конфликтует. На первой конторе с одним пакетом построенным на стандартном функционале навидался таких костылей что больше не хочется с этим связываться.