Игорь Столяров писал(а): 16 Апрель 2023, 14:03
1. Вы настаиваете, что пользователи тупые и обязательно накосячат, если разработчик
предоставит им возможность делать что-то из того, что по его мнению им делать не нужно.
Перевернули все ровно наоборот. Никто не писал, что пользователи тупые. Речь о том, что если есть возможность ошибиться, то ошибутся обязательно. Применительно к последней теме, если могут пропустить какой-то документ при ручном выборе, то обязательно будут случаи такого пропуска. Конечно, вероятность ошибок существует всегда. Чем более специализированная система, тем меньше вероятность ошибок, так как люди работают в более привычной для них среде, без лишних абстракций, лишних телодвижений.
Разработчик автоматизирует бизнес-процессы не исходя только из своего мнения, а в процессе сотрудничества с пользователями. Пользователи, как правило, не разбираются в технологиях, но имеют опыт работы в предметной области. Автоматизация в конечном счете это некий компромисс и результат диалога. Чем больше опыта у разработчика, тем лучше и быстрее он понимает реальные потребности пользователей.
Игорь Столяров писал(а): 16 Апрель 2023, 14:03
2. Я пилю за то, что разработчик должен создать некие специализированные примитивы
(товар, отчёт, заказ и т.д.) и пользователям тогда будет удобней манипулировать ими вместо ячеек.
Разница в степени погружения в предметную область. Как только Вы начинаете понимать, какие нюансы возникают при работе бизнеса, то начинаете переходить к более специализированным инструментам. То есть, Вы можете оперировать в качестве примитива понятием отчет, а можете более конкретно "Оборотка по товарам поставщиков" и т.п.
Игорь Столяров писал(а): 16 Апрель 2023, 14:03
Вы на любое моё описание применения выбора записей - сразу описываете как такой функционал реализован у Вас.
Я абсолютно не сомневаюсь, что у Вас всё реализовано и даже могу предположить, что сделано нааааамного больше.
Потому, что Вы реализуете каждую операцию в готовом виде. А все ли эти готовые операции сейчас ещё используются ?
Не очень понял вопроса. Если речь о полноте функционала, то предусмотреть всего сразу невозможно. Мы уже про это говорили. На каждом этапе развития бизнеса появляются новые потребности, о которых ранее никто и не мог предположить. Поэтому разработчик не просто слушает пользователей и реализует их хотелки, а анализирует, как эти хотелки вписываются в технологию. И таки да, иногда пользователи могут получить отказ, хотя, как правило, всегда находится некий компромисс.
Если речь об избыточности функционала, то да, некоторые разработанные схемы могут повиснуть в невостребованных. Система настройки позволяет скрывать лишнее. Иногда приходится сдерживаться, чтобы не пытаться объять необъятное, стараться подтягивать пользователей на использование какого-то функционала. Если с функционалом никто не работает, то постепенно он может прийти в неактуальное состояние. Это все непростые вопросы.
Мы просто пишем про разные категории софта. У Вас он менее специализированный, в надежде на охват более широкого круга пользователей. Ну, ок, им пользуются, значит кому-то нужен такой уровень автоматизации. А есть люди, которым нужен более высокий уровень автоматизации (а главное, уровень контроля за информацией), тогда они используют более специализированную, заточенную на их бизнес систему. На верхней ступени специализации стоят заказные приложения. Но для их промышленной разработки нужно хорошее финансирование, в наших условиях сложно найти.
C6/C12, ШВС, tps/btrieve.
После обнаружения фичи в стандартном Message, я написал свой аналог вызова через Windows API. 
