Сказанное далее не бахвальство, а подход эффективность, которого была подтверждена результатами эксплуатации
/речь идет о бухгалтерских АРМ "Учет труда и заработной платы", "Учет материалов на складах", .../

И так /вкратце/ об общей подходе к архитектуре и разработки этих АРМ /Foxpro/.
Ручного кода было процентов 5.
Каким образом?
Были разработаны:
- генератор исходных текстов для формирования отчетов;
- designer форм;
- настраиваемое иерархическое меню /а-ля плиточная технология Microsoft (но это было реализовано в 90-х)/

Так вот генератор исходных тестов для отчетов и designer форм не просто создавали абстрактный исходный код,
а помещали его в prg так, что имели логически связанный исходный код.
/кому интересны детали см. Чем заменить FoxPro? http://www.sql.ru/forum/907180-36/chem-zamenit-foxpro/

Теперь об архитектуре АРМ.
Каждый из видов учета имеет определенный набор бухгалтерских операций и документов.
Реализованы они были с использованием одного или нескольких prg.
И в основном их задача сводилась к подготовке исходных данных /табеля, премии, наряды, ... ... .../.
Многие исходные данные порождали некоторые расчетные данные ...
К чему об этом говорю?
А вот к чему.
Не важно отработала транзакция или нет /например свет пропал/.
Бухгалтер всегда мог заново произвести расчет или иное иное какое-действие /не ввод данных/ и
ни какие внешние факторы не создавали проблем с целостностью данных, актуальностью ...

Все АРМ содержали manager пакетной обработки.
Что он из себя представлял?
Это был DBF файл в котором была помещена информация в каком порядке какие модули prg запускать.
Что в результате имели?

Бухгалтера готовили данные жали кнопку - "Хочу все" и ждали результат.
Модуля запускались в определенном порядке сначала делаем начисления /табелей, премий, .../.
Затем производим удержания.
Т.е. практически АРМ делал все то, что без пакетного manager они должны были произвести
вручную /через пункты меню, .../

Что нужно было им знать если к примеру пропадал свет?
Одно как нажать на кнопку - "Хочу все"

PS: Еще раз повторюсь кнопка "Хочу все" была во всех АРМ.

skyANAДля кого? Насколько эффективно с этим работают пользователи далёкие от программирования?Ни как не использовали.
Бухгалтерам без разницы какая там программная архитектура АРМ.
У них другие приоритеты ... /работал с многими клиентами - были довольны/.

vill_agerа чем родные фокпрошные не устраивали?Владимир2012/кому интересны детали см. Чем заменить FoxPro? http://www.sql.ru/forum/907180-36/chem-zamenit-foxpro/

skyANAБухгалтеры использовали генератор и дизайнер для создания новых отчётов и форм, или только настраивали иерархическое меню?Ни чего они не использовали /хотя могли/.
Их устраивало вполне то, что они "ставили" задачу и получали то, что хотели.
По "Учету труда и заработной платы" процентов 90 бухгалтеров не могли правильно произвести удержание
подоходного налога /разве что в простых случаях/.
Но 10% не пропускали ни один из моих "промахов".
Суть ведь не в моей программной реализации, а в организации интерфейса и всяческих "удобств" и
оптимизаций для эксплуатации АРМ /то же не моя заслуга, а заслуга бухгалтеров (всяческие пожелания ...)/ .
Интерфейс АРМ "Учету труда и заработной платы" /да и других АРМ/ предоставлял бухгалтерам настроить его под "себя"
/используемые на предприятии коды, .../.
Поэтому с адаптацией АРМ к клиентам /торговая организация, завод, .../ не было ни каких проблем
/разве что был некий набор специфичных для вида производства форм/.
Просьба не задавать вопросов по тематике бухгалтерского учета, организации интерфейсов, ...
По приведенной в начале topic ссылке можно получить ответы на многие вопросы.

Цель этого topic - показать общий подход к программной архитектуре и пользовательскому интерфейсу.

skyANAТо есть новые отчёты и формы писали исключительно Вы?Да.
В те времена у меня не было цели реализовать какую-либо технологию для разработки информационных систем.