В чем рисуете СХЕМУ программы?

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

0

Привет. Использую UML в Umbrello.

0

Сообщение от ganeevez Добрый день! При создании большой программы, а также спустя некоторое время в голове начинает не хватать места, забываешь где чего делал, теряется общая логика программы, приходится по новой изучать свой ранее написанный код, чтобы встроить бизнесс-процесс. Подскажите пожалуйста, в какой программе можно было бы рисовать СХЕМУ программы, чтобы потом с легкостью вспоминать какой блок за что отвечает?

Никогда не рисую схему программы.
Если хорошо разбить на файлы, хорошо их назвать и хорошо сгруппировать по папкам, то потом легко вспомнить, какой блок за что отвечает.

0

Shamil1, когда еще нет файлов, директорий и т. п., полезно архитектуру/взаимодействие будущих компонентов продумать заранее, если это не приложение уровня hello world. И нарисовать диаграмы. И просто необходимо уметь это делать, если разработка идет командная.

0

Сообщение от Заблудившийся И просто необходимо уметь это делать, если разработка идет командная.

Зачем?

0

Shamil1, чтобы найти потенциальные ошибки, возможные проблемы еще на стадии проектирования. Или изменить сам подход. Это сложно сделать на словах, а на схеме - это прозрачно и просто.
Если взять самое банальное, при работе в команде, когда владелец компонента А может не знать точно, как работает компонент Б. Когда для добавления нового функционала, готовы все UML-диаграммы, собрана команда, в диаграме владелец компонента Б, может это легко увидеть: нет, чувак, его так не получится использовать, как здесь нарисовано. Тогда меняем подход. Когда архитектура принята, все взаимодействие, интерфейсы описаны, разработка становится проще и предсказуемее.
Формализованный язык схем позволяет избежать многих проблем недопонимания между людьми, чем когда обсуждение ведется текстом, или устно. Намного реже возникают ситуации "а я совсем не это имел в виду" и "мы договаривались не так..." потому что то, что все имели в виду, закреплено UML'ем.
Это как, если один математик будет другому объяснять свою мысль общиким словами. Возможно, в принципе. Но эффективнее и понятнее будет другому математику - формулы рассчетов. Одна формула - стоит тысячи слов. Одна UML-диаграмма - стоит тысячи слов и названий еще не созданных файлов и директорий.

0

Сообщение от Заблудившийся Если взять самое банальное, при работе в команде, когда владелец компонента А может не знать точно, как работает компонент Б.

Как работает - это список открытых методов? Можно написать на листочке. А если что, то можно попросить добавить пару методов.

Сообщение от Заблудившийся Когда для добавления нового функционала, готовы все UML-диаграммы

Написать предварительный вариант кода ядра Системы займет меньше времени, чем подготовка окончательного (больше никаких изменений!) варианта UML-диаграмм.

Сообщение от Заблудившийся Это как, если один математик будет другому объяснять свою мысль общиким словами.

Плохая аналогия. Код является очень строгим описанием, а не общими словами.

0

Сообщение от Shamil1 Как работает - это список открытых методов? Можно написать на листочке.

Для описания интерфейса тоже есть тип UML-диаграмм. Листочки со своими придуманными знаками для описания интерфейсов, наследования, методов и свойств не нужны, так как каждый пишет, как хочет.

Сообщение от Shamil1 Написать предварительный вариант кода ядра Системы займет меньше времени, чем подготовка окончательного (больше никаких изменений!) варианта UML-диаграмм.

Это лишь говорит о том, что ты не писал больших "ядер" в большой команде.

Сообщение от Shamil1 Код является очень строгим описанием, а не общими словами.

До того, как начать писать код, нужна правильная архитектура. Ее невозможно писать словами, как и план дома перед постройкой.

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

0

Сообщение от Заблудившийся Это лишь говорит о том, что ты не писал больших "ядер" в большой команде.

Или об умении разбивать большие задачи на слабо связанные задачи по-меньше?

Сообщение от Заблудившийся До того, как начать писать код, нужна правильная архитектура.

Зачем?

0

Сообщение от Shamil1 Зачем?

Это какая-то старая вера школа... ~Всё зарегулируем и пропишем заранее, чтобы исполнителю мозги не требовались.

Сообщение от useruser Откат, слияние, ветки но только не четкое техзадание, распределение обязанностей, личная ответственность.

1

Нарисовать детализированную диаграмму занимает много времени. Если проект действительно большой и сложный, то всё учесть практически невозможно. В процессе реализации найдутся места, которые лучше делать не так, как собирались сначала. (Где-то код дублируется, где-то нельзя составить запрос к БД, который получает требуемую информацию за приемлемое время и т.д., и т.п.) Значит, придётся переделывать диаграмму. ИМХО единственный способ убедиться, что диаграмма составлена правильно - это написать соответствующий код.
Даже если в команде есть гениальные архитекторы, которые могут сразу нарисовать окончательный вариант диаграммы (зачем им диаграмма, если они и без неё знают, как делать?), то всё равно её придётся переделывать из-за того, что изменятся требования/пожелания заказчика. Ни один клиент не может сразу описать, что ему нужно. Это не потому, что клиенты глупые, а потому, что нечто, что кажется удобным в теории, может оказаться неудобным на практике.
Даже если у клиента есть гениальный дизайнер интерфейсов, который сразу выбрал самый удобный вариант, то всё равно придётся переделывать из-за того, что со временем требования/пожелания изменятся. Конечно, можно попытаться предусмотреть все будущие изменения и спроектировать архитектору программы так, чтобы их можно было реализовать без изменения ядра системы. В результате получится супер-универсальный монстр с кучей ненужных фич "на всякий случай". Создавать и поддерживать такого монстра обойдётся дороже, чем держать архитектору максимально простой и изменять, когда требуется новая фича.
Диаграммы хороши в теории, а на практике, начиная новый проект, нужно ожидать, что архитектура системы изменится. Обязательно. Хотя, пока, не известно, в каком месте, как и по какой причине.

С использованием современных средств рефакторинга проще изменить код, чем внести соответствующие изменения в диаграмму (ну или, по крайней мере, не намного сложнее). С точки зрения планирования составление и поддерживание диаграммы в актуальном состоянии несёт мало пользы. Если так уж необходимо, можно во время обсуждения нарисовать фломастером на доске диаграмму для части системы, которая вызывает разногласия или непонимание. А поддерживать диаграмму в актуальном состоянии - это дополнительная, причём довольно муторная работа.
С точки зрения понимания, что делает код, диаграмма тоже не нужна. Если система построена хорошо, то уже по названию проекта/класса/метода понятно, что делает код внутри. Благодаря современным средствам разработки, глядя на метод я сразу вижу, в скольки местах он вызывается, сколько раз менялся за последний год, сколько багов было исправлено и т.д. При необходимости, я могу сформировать аналогичную информацию отдельно для каждой строчки кода. Это гораздо быстрее и удобнее, чем рыться в диаграмме, занимающей 20 листов А4. Лично я даже диаграммы таблиц в БД перестал использовать (когда в БД 100+ таблиц, замучаешься скролить в нужное место - проще посмотреть список ключей для нужной таблицы).

1