История изменений

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

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