Как понять свой проект на python, построенный по принципам чистой архитектуры, начинающему?

Question

[Леонид ---]

Я, как начинающий разработчик проектов на python, имею много вопросов касательно понимания проекта, который спроектирован по принципам SOLID:


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

Прилагаю мой проект - репозиторий с GitHub -> https://github.com/xaocit/MyManager.git

Comments

[VoidVolker]

Подскажите, что и как лучше всего сделать, чтобы понять свой проект.

Это же ваш проект, как это его можно не понимать? Вот вы же его придумали и не можете понять что именно вы придумали? Или может вы просто не можете правильно сформулировать свой вопрос? Трудности с проектированием? Не можете применить какой-то паттерн архитектуры непосредственно к вашему проекту? Вам следует его реализовать самостоятельно полностью с 0 до 100%, а так же заниматься его поддержкой и развитием. Т.е., ТЗ, ЧТЗ, планирование, проектирование, разработка, отладка, исправление багов, доработки, сопровождение и прочее. Это даст вам опыт, на который и можно будет опереться при разработке следующего проекта или же обновлении уже существующего.
Вот тут есть несколько примеров диаграмм реальных проектов: https://qna.habr.com/answer?answer_id=2505330#answ...
В целом же, могу посоветовать для начала реализовать просто чтобы оно работало. Не имеет значения как именно. Понимая, как именно он работает уже можно попробовать реализовать какой-то паттерн архитектуры/логики. Чтобы было с чем сравнивать и от чего отталкиваться, дабы понимать зачем и почему сделано именно так, а не иначе.

Answer 1

[Пума Тайланд]

Забей на диаграмму каждого метода — бери один сценарий и трассируй его дебаггером с брейкпоинтами, смотри call stack. Для «добавить транзакцию» примерно так:

ConsoleUI._menu_add() → TransactionService.add() → repository.save_all()

.

Кстати UI у тебя лезет прямо в self.service._transactions, то есть знает внутренности сервиса напрямую — вот это и есть реальное нарушение границ слоёв, а не то как называются папки.

SOLID зубрить не надо, возьми маленький сценарий и попробуй сменить в нём JSON на SQLite. Сразу станет видно зачем нужны интерфейсы и DIP.

Comments

[Пума Тайланд]

Да и в целом в мире где вайбкодинг уже по сути победил зачем тебе это надо? Я уже даже перестал код читать хотя мне пятый десяток, а ты молодой и зачем то тратишь свою жизнь на это

[Леонид ---]

Пума Тайланд, Спасибо за наставление про нарушение границ слоёв - я понимаю, что вы говорите про то, что не нужно, чтобы извне мы обращались к защищённому атрибуту _transactions, а использовали методы self.get_transactions(), например.

Насчёт этого
бери один сценарий и трассируй его дебаггером с брейкпоинтами, смотри call stack.
- я так понимаю, что вы предлагаете через режим отладки посмотреть цепочку вызовов методов и всё?

Касательно того, зачем мне это надо, я просто теряюсь в коде, когда размер превышает +- 500 строк - приходится долго листать от одного до другого и добавление 1-й фичи занимает много времени даже несмотря на то, что архитектура более менее соответствует требованиям.

[Пума Тайланд]

пишите через ии ) Леонид ---,

[Леонид ---]

Пума Тайланд, Я без понятия как делать это в VS code. Вручную не получится просто пройтись и просмотреть что за чем идёт? Например:

[Леонид ---]

Пума Тайланд, На мой взгляд выглядит непонятно с первого раза, но если разобраться, то ок - https://miro.com/welcomeonboard/WEhtUWoxRk5lcndQUk...

Жду рекомендации, как можно улучшить графы, чтобы можно было посмотреть и сразу понять... =_=

[Пума Тайланд]

Леонид ---, дебагер сперва научитесь использовать

Answer 2

[Евгений]

Я бы начал вообще с мысли, что для обучения существуют учебники и хорошие курсы. Они как раз создаются для того, чтобы новичку не приходилось самому ломать голову над тем, с чего начать и в какой последовательности изучать материал.
Поэтому на старте я бы не пытался самостоятельно выстроить идеальный маршрут из ООП, SOLID, паттернов и архитектуры. Гораздо разумнее взять хороший учебник по Python, пройти его последовательно и параллельно писать код руками.
А дальше уже идти от простого к сложному:
Python → функции и процедуры → модули → классы → ООП → несколько небольших проектов → SOLID и паттерны → архитектура
После этого уже появляется собственный опыт и реальные проблемы. Классы могут становиться слишком большими, модули — сильно зависеть друг от друга, код становится трудно менять. И тогда SOLID и архитектурные решения воспринимаются не как набор непонятных правил, а как способы решения конкретных проблем.
При разборе больших проектов я бы тоже не пытался сразу понять всю архитектуру. Лучше взять один сценарий и проследить его выполнение
То есть я бы строил обучение по принципу:

сначала учимся писать → сталкиваемся с проблемой → узнаём способ её решения → применяем → понимаем, зачем он нужен.

А не наоборот: сначала учим архитектуру, а потом пытаемся понять, какую проблему она вообще решает.

Comments

[Adamos]

с мысли, что для обучения существуют учебники

Вообще-то на этом мысль можно было закончить ;)
Только учитывая, что хороший учебник для новичка, хороший учебник для изучающего третий-пятый язык, хороший учебник по конкретному языку со всеми его нюансами и хороший учебник по программированию вообще - это десяток совершенно разных учебников.
И, разумеется, хвататься за каждый из них имеет смысл только на этапе созревания читающего для усвоения прочитанного.

[Леонид ---]

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

[Adamos]

Леонид ---, главная проблема - это мотивация.
Легко бросить учебник и схватиться за другой, бросить его и пялиться в видосики курсиков.
Трудно - грызть гранит и биться лбом самому, постоянно практикуясь и используя учебник как указатель, куда двигаться дальше, а не как "мерило работы".
Но без этого преодоления так и останешься нахватавшимся, а не научившимся. Как бы хороши ни были видосы и раскручены гуру, их настрогавшие.

[Евгений]

Леонид ---, В этом плане неплохо помогают книги и лекции Брайана Трейси — «Съешьте лягушку!», «Выйди из зоны комфорта», «Психология достижений». Особенно хорошо заходят мысли про самодисциплину, регулярную работу и доведение начатого до конца. Хорошо перекликается с тем, что учебник должен быть инструментом, а не заменой самостоятельной практики.