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

Программирование блок схема

Igr

Уфа

144

2 655

с 30 марта 2013

24 Комментария

Тихий омут
06 марта 2019, 14:48
Уууу. тут у нас как в стране «дикий капитализм» так и среди программистов-самоучек «дикий программизм»

90% ограничивается комментариями в коде. а еще 10% и того не делают :-)

в крайнем крупная логика может быть на начальном этапе прорисована схемой. А затем по мере жизни проекта исправления ошибок и внесения корректировок в код, схема постепенно перестает быть актуальной а перерисовывать лень.
+4
- Igr
  06 марта 2019, 14:54
  Андрейка, я коменты почти к каждой строчке ставлю, но это не даёт виденье общей картины, недавно не учёл один момент и потратил время на поиск ошибки, вот и задумался может схему нарисовать, но чёт она получается слишком громоздкой, вот и думаю как проблему решить
  0
  - Value
    06 марта 2019, 16:17
    Igr,
    
    я коменты почти к каждой строчке ставлю, но это не даёт виденье общей картины
    
    Нужно писать и читать на языке программирования, а не на языке комментариев. Комментарии, которые просто дублируют код не дают ничего, только отнимают время.
    +3
- VladMih
  06 марта 2019, 21:19
  Андрейка, блок-схема — это принципиальная схема вашего проекта.
  Если пришлось её перерисовывать (не путать с ДОрисовывать),
  значит ваш изначальный проект провалился и нужна новая блок-схема.
  0
Тихий омут
06 марта 2019, 14:52
я стараюсь делать самодокументированный код + комментарии,
на начальном этапе идеи крупная схема + краткое описание логики в ворде/экселе.
+1
- Igr
  06 марта 2019, 14:55
  Андрейка, самодокументированный код — это что такое?
  0
  - Тихий омут
    06 марта 2019, 15:00
    Igr, самодокументированный в яндексе самая первая ссылка https://tproger.ru/articles/15-tips-selfdoc-js/
    
    В кратце: имена функций — глаголы, имена переменных существительные, классы с большой буквы, экземпляры с маленькой, вообще там много всяких требований к такому коду
    
    +1
Dmitryy
06 марта 2019, 14:55
В самом простом случае «блок схема» (в гугле полно картинок, как это выглядит). Если система сложная, то используют UML диаграммы (тоже легко гуглится).

Хорошо продуманная до мелких деталей UML диаграмма — это уже огромная часть системы.
+1
- Igr
  06 марта 2019, 15:01
  Dmitryy, вручную рисуете или какой то прогой пользуетесь?
  0
  - Dmitryy
    06 марта 2019, 16:01
    Igr, обычно в визио или онлайн подобном редакторе, типа https://www.draw.io/
    0
- Тихий омут
  06 марта 2019, 15:04
  Dmitryy, диаграмму поддерживаешь в актуальном состоянии?
  0
  - Dmitryy
    06 марта 2019, 16:03
    Андрейка, нет, у нас проект бьется на фазы, диаграммы описывают фазу изменений, её сделали, переключились на следующую. Поддерживать один большой док на весь проект — это очень трудо-затратно. И в конечном счете бесполезно, т.к. новички его не читают и не понимают.
    0
Юрий Быков
06 марта 2019, 16:14
Опишите сначала для себя что вы хотите реализовать и желательно подробно. Какие данные на входе в программу, что должно получаться на выходе. Всем переменным/функциям давайте говорящие имена (а не x, y, z), с таким подходом приблизитесь к самодокументируемому коду. Всю бизнес-логику оборачивайте в функцию, даже если в функции будет одна строчка и функция вызовется только один раз, это поможет в будущем и сформирует полезную привычку. По поводу самой логики советую почитать https://www.ozon.ru/context/detail/id/35045716/
+1
Value
06 марта 2019, 16:19
Вы слишком усложняете. Просто делайте декомпозицию и пишите такой код, который сам расскажет, что происходит.
+2
XXM
06 марта 2019, 16:47
Без блок-схемы — ни шагу:

Рисунок из 2016 года (https://smart-lab.ru/blog/322198.php)
+1
Виталий Саханов
06 марта 2019, 16:59
В виде короткого текста, с существенной информацией.
+1
netbook
06 марта 2019, 17:33
Как сказал когда-то Ron Jeffries: «Code never lies».
+2
- Value
  06 марта 2019, 17:47
  netbook, «Code never lies, comments somtimes do». © Ron Jeffries
  +2
  - netbook
    06 марта 2019, 18:18
    Value, вот именно
    0
Гончар
06 марта 2019, 18:07
не видел еще таких сложных проектов где нельзя было бы перевести в горизонтальную плоскость с 2-3 уровнями вложений. А для этого блок схема ненужна
0
Михаил
06 марта 2019, 18:17
На мой взгляд блок-схемы нужны, если ты работаешь в группе, чтобы попилить работу.
А так сильнее структурируй код: дели на отдельные пакеты, модули, классы и функции. Функции должны быть очень меленькими и делающими одну продую вещь, название функций и переменных должно быть говорящим за себя. Пишу доктриги, но избегай комментарии. Если нужен комментарий, скорее всего ты написал плохой код.
+2
Андрей К
06 марта 2019, 19:57
Надо вам ребята, что нибудь на низком уровне покодить =))
0
bwc
06 марта 2019, 22:15
комментарии в коде, если он тривиальный и пишется сразу, без подготовки
иначе — сохранять всё что можно: требования, бумажные черновики, прототипы (git!) и т.п. со временем потребуется восстанавливать весь процесс: что хотелось сделать, какие рассматривались варианты и почему были выбранны именно такие решения.

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

описания могут иметь различный масштаб.

вбщм всё сильно зависит от сложности, объёма и как сильно вы отвлекаетесь от этого кода.

p.s.: на бумаге удобно прорабатывать навороченное ветвление (чем сразу писать код). хорошо видна последовательность принятия решений и наличие непокрытых вариантов.
+1