juliion

Сначала замечания по реализации:

1. Раз уж мы делаем свой аналог List - тогда есть смысл вынести его в библиотеку, а не с Exe.
TargetFramework стоит делать чуть более новым. Сейчас LTS - .NET 6 (но это не так уж и критично)

2. Почему List Только для char реализован? Почему не сделать его обобщённым?

3. Почему List не реализовывает стандартные интерфейсы? Тот же IEnumerable<T> хотябы.

4. PrintForward - явно какой-то лишний метод. Список не должен отвечать за вывод в консоль.

5. Публичный сеттер в Node выглядит как что-то опасное. Так можно изменить Next или Previous - лист изменится, вплоть до изменения количества элементов, но значение Count в самом листе не изменится, от чего всё поломается.

А вот тесты наоборот выглядят вполне неплохо, но надо бы покрытие посмотреть.

1. Не ясно зачем использовал старый .net framework
2. Зачем у Score публичные геттеры-сеттеры, если по идее класс иммутабельный и у него даже конструктор с обязательными параметрами есть?
3. Везде есть привязка к русскому языку, что не очень хорошо, но и не смертельно.
4. Есть небольшая проблема с именованием методов, но не критично
5. Стандартная бинарная сериализация - зло почти всегда.
6. Пароли в открытом виде, и даже нет никакой абстракции над форматом хранения данных (если бы была абстракция, то уже не так критично было бы)
7. Относительные пути (нашёл в Manager.cs). Сами по себе относительные пути - это не плохо, но тут аж в родительскую папку стучится.
8. Не понятно, почему есть всего три захардкоженных вида викторин. Разницу между ними по коду я не увидел.
9. Главное меню в процедурном стиле с совершенно неговорящими именами методов и константами - ну это совсем уже ни в какие ворота.
10. Нравится, что сразу есть разделение на два bounded context - прохождение викторин и создание. В принципе не сложно будет зарефакторить.

Дальше не буду проверять. Кажется, что автор просто не достаточно проработал предметную область и не проработал архитектуру приложения, на основе этого.

Советую почитать книги:
"Чистая архитектура" Роберта Мартина
"Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем" Эрика Эванса

Не обязательно прямо целиком книги - можно просто почитать статьи и посмотреть доклады про то как следует строить архитектуру приложений.
Вкратце:
1. Старайся не смешивать модель предметной области и детали реализации
2. Если делаешь обогащённые модели (с методами, которые отражают суть предметной области), то используй их повсеместно.
3. Если делаешь анемичные модели - делай их повсеместно. Не стоит в рамках одного контекста смешивать оба подхода
4. Код в идеале должен выглядеть так, чтобы было сразу понятно, что происходит и почему. Также должно быть очевидно, где и что нужно искать.
5. В идеальном мире, код должен быть такой, что если бы тебе дали задачу "перенести это всё в веб", тебе бы вообще не пришлось никак менять код ядра (в данном случае проект QuizModel), и при этом не пришлось бы дублировать код из QuizCreator и QuizApp