Максим Кузнецов

Данные надо проверять там, где они есть (гуглить "GRASP информационный эксперт").

В вашем случае мы говорим о "входящих данных". В контексте вопроса стало быть мы говорим о контроллере. Для модели данные тоже будут "входящими" но это уже будут данные в формате модели (например вместо строки готовый DateTime объект и т.д.)

Модель же не должна входить в "невалидное состояние" за счет бизнес правил и т.д (банально не должно быть возможности вызвать какой-то метод и сломать целостность состояния модели). А стало быть валидировать ее нет смысла.

scrapy
или
grablib

Проект развивается итерациями и фичи нагромождаются и код, естественно, не самый изящный и простой для понимания и анализа.

Тесты, TDD, рефакторинг, SOLID. И тогда нет боли. Но это увы далеко не на каждом проекте встретишь.

Потому, как, тебя просят добавить или починить функцию А, ты ее чинишь, но попутно, возможно, ломаешь явно фичу Б и неявно В

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

Так вот, по идее, мне кажется, что возможно организовать разработку так, чтобы этих вот багов было минимум.

Баги это хорошо, регрессионные баги это плохо, это показатель того что с нашим кодом что-то не так. Уменьшить количество багов просто - нужно больше тестов с учетом различных инвариантов. Но иногда это избыточно, и проще просто словить и пофиксить баг.

Так же рекомедную вам ознакомитсья с практиками экстримального программирования, там много внимания удиляется обратной связи от момента когда разработчик что-то сломал до момента обнаружения проблемы (парное программирование, TDD).

А дело то как раз в условиях контракта. 1) Описаны ли приемосдаточные мероприятия? 2)Описана ли дальнейшая поддержка продукта(т.е. что будет если выйдя за порог вашей компании - игра развалится в руках заказчика). 3) ТЗ. вы в одностороннем порядке включили сторонную платную либу, а заказчика уведомили? ну так, смеха ради. Или решили сюрприз сделать? Ваша позиция слабовата. Мое мнение - я, как заказчик, выставил бы вам счет за ПО, которое мне пришлось купить ради работы вашего продукта. Вам пришлось купить либу? Без проблем - вычитайте стоимость из вашего гонорара и покупайте что хотите. Вы должны предоставить рабочий продукт, а вы хотите подсунуть пучок кода, который вроде заработает, если дополнительно прикупить некую библиотечку.

Не путайте стек технологий и язык.
Сам по себе язык ничего не дает, он связывает разные компоненты определенной логикой.
Зависит от того, что вам нужно. Нужно писать под мобильные девайся - учите стек мобильных технологий. нужно писать под веб - учите веб. Нужно писать в команде - учите командные инструменты и стилистику.

попробуйте поискать mind map-ы вроде таких:

zeroturnaround.com/wp-content/uploads/2014/06/jtnt...

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов

Не роутер, обычно фасад нужен для того, чтобы скрыть сложный и разрозненный функционал и предоставить некое API для управления всем этим хозяйством.

По-видимому ваша компетенция не в сфере ЭС, а в сфере программирования. В таком случае попробую подсказать по ЭС.

Формально говоря (есть в каждой книжке по ЭС в первой главе) экспертная система - это готовая система для которой произведен сбор знаний, их инжиниринг и внедрение итд, по процессу. А для разработки используют Expert System Shell - оболочку ЭС. далее я везде имею ввиду оболочку.

Шаг первый - узнать что существует. для этого советую изучить Jess по книжке jess in action. jess - намного лучшая реализация CLIPS, плюс использование джавы добавляет батареек.

Потом посмотреть JBoss DRools, в нем есть побольше функций, в частности backward chaining (это есть и в Прологе но там нету forward chaining)
Раньше алгоритм Rete не везде был реализован, но сейчас кажется есть во всех нормальных ОЭС.

Шаг второй - посмотреть что можно добавить. Есть книга Питера Джексона Введение в экспертные системы там описано много функций из экспериментальных или научных экспертных систем, и редко более двух реализовано в одной оболочке ЭС. Их и можно добавить.
Там их достаточно, а если нет, можно спросить.

Теперь ответы, по обратному порядку:
3. Можно приспособить ко всему к чему есть экспертные знания (ну или "экспертные" - не суть. можно начать и приловчиться - в любой сфере. главное желание и энергия)

Но например, как сейчас стали ЭС использовать.
Стали применять в бюрократиях для замены начальников и прочих проверяльщиков из бюрократии на систему с правилами настроенными на проверку бумажек. точнее анкеты вводятся в электронном виде девочкой-оператором, и ЭС их проверяет. вплоть до проверки можно ли давать кредит и тп.
В общем эффективные менеджеры МБА-шники взяли микроскоп информатиков из 80ых и применяют для своих целей, заколачивания пары медных гвоздей, в виде экономии на бюрократии.

2 "Что нужно реализовать в ней?" - то чего не хватает в выбранной оболочке ЭС. может уже есть, смотря задача. для автоматизации и замещения бюрократов механическим бюрократо-автоматом уже все есть, кажется.
А может для задачи чего-то не хватает. или алгоритмы медленные. Если хорошая сложная задача, может и так случится. Изобретатель алгоритма Rete например, новые версии сделал платными и защитил патентами.

1. "как себе видят ЭС в понимании обычного пользователя, не только разработчика?"
Для примера наверху.
Если визуально - то оператор видит окошки ввода полей анкет или окошки для конкретной операции и в конце - дзинь - сообщение вида "фамилия не введена" или условно, максимум, "кредита не выдавать" или скажем еще какая машинерия, требующая вмешательства в ральности, типа запросить подпись, или паспорт клиента.

А тот кто пишет правила видит либо текстовые поля как программист, либо "более визуальное" типа Query builder-a в MS Access, для тех же правил.

Я бы порекомендовал изучить официальные примеры