Gaba-Zhaba

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

Подхода два - от интерфейса к логике или наоборот - от логики к интерфейсу. Что лучше, что хуже - вкусовщина. От интерфейса к логике получается немного более по "KISS-овски" и "YAGNI-вски", так как накидываешь только те фичи, которые хочешь реализовать. От логики к интерфейсу работать тоже можно, но тут есть риск уйти в преждевременную оптимизацию.

Дальше логика разбивается на блоки задач и модели данных. К моделям определяешь, какие действия с ними надо будет совершать - так определяются методы. Здесь же определяешь сигнатуры этих методов (параметры, их типы, возвращаемые значения). Если проект крупный - то тут уже неплохо было бы UML схемку набросать.

После того, как определил иерархию классов, можно уже запускать IDE и сразу создать определения всех классов которые ты нарисовал на бумаге. В каждом классе рисуешь заглушки методов (можно сразу помечать комментарием TODO, чтобы ничего не опустить).

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

Ну вот уже после всего этого, начинай писать код. Тебе будет легко и приятно. Ты будешь примерно представлять, сколько ты уже сделал, и сколько ещё осталось. Баги будут вылавливаться тестами, и ты не будешь писать лишний код, которым никто не будет пользоваться в дальнейшем.

Возьми листик начерти как будет работать своя программа. Я когда на питоне пишу большие программы с классами всегда так делаю чтобы не запутаться в коде.

Это называется "архитектура". Если вы начинающий и хотите создать приложение с более-менее хорошей архитектурой, попробуйте какой-нибудь известный в вашем стеке фреймворк. Фреймворки зачастую диктуют свою архитектуру или имеют готовые шаблоны проектов, в которых предусмотрена "тысяча мелочей". Так же вникание в премудрости архитектуры можно / нужно начать с изучения паттернов (factory, dependency injection, adapter и т.п.) и подходов (MVC, TDD, SOLID, DRY и т.п.)

А вот что касается именно бизнес-логики, тут все слишком специфично и зависит от предметной области. Я бы посоветовал в ходе разработки временами задумываться на тему "как потом я смогу расширить этот модуль/класс/метод, не редактируя его код?". Это временами даёт очень годные идеи.

Если проект очень важный, посмотри в сторону методологии TDD.

Вы не научитесь писать и проектировать программы, если самостоятельно не набьете на этом шишек.

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

После нескольких таких заездов по граблям вы получите опыт - ошибки и трудности, с которыми вы начнете сталкиваться будут такие, что ни в книге сказать, ни на StackOverflow прочитать.