Вопрос такой... устал от разного рода shapes draw
Кто какие инструменты использует для проектирования того как будет выглядеть решение в схематичном виде?

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

Я пока что все это по старинке... рисую )))

А кому нужен результат этого труда? Вы архитектор системы?

СППР

(0) Не дорос я, задачи в голове

СППР, когда процесс сложнее четырех этапов.
Остальное - в голове.

(1) самому себе же и нужен.

(0)
Пользуюсь этим, даже лицензию купил
https://www.literatureandlatte.com/scapple/overview

Notepad, Excel.

сначала на бумажке, потом (если не очевидно) картинку в vscode  с плагином http://plantuml.com

(1)Мне нужен.. А через пол года - так прям очень нужен бывает)))

(8) Интересно и довольно просто. Спасибо

Visio, Excel

(9) Зачем? В 1С код самодокументируемый.

(12) вопрос опять не ко мне, но я опять отвечу:
1. Чтобы самому с собой договориться
2. Чтобы сравнить варианты архитектуры и выбрать
3. Чтобы договориться с коллегами (ну, это для тех, кому есть с кем договариваться)

(12) что значит самодокументируемый?

(14) видимо сам комментарии генерит)

Кстати странно, что эту тему редко поднимают. У меня тоже это больная проблема.

(14) Значит откройте код и почитайте.

Поддержу (1) . Никому не нужен результат этого труда.

(13) Хы :-) Понравилось - "...(ну, это для тех, кому есть с кем договариваться)"
Прям в точку.

(18) это просто отражение частного опыта

(17) проектирование нужно ПЕРЕД тем, как код будет написан. А иногда даже и просто - вместо этого.

проектирование ради документирования - действительно мартышкин труд. ХОтя, люди иной раз занимаются и им

(21) См. (9)

(23) ну, это иллюзия от недостатка опыта. Реальная практическая ценность логической модели ПОСЛЕ реализации действительно очень низкая. Хотя бы потому, что после реализации никому без специальных п**юдлей не придет в голову поддерживать в актуальном состоянии модель при доработках.
Реальные смысл и польза от моделей - они ДО реализации.

(23) такой метод нам знаком: х..к, х..к и в продакшн

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

Хотя есть компании, в которых работают дивные руководители, считающие, что любое сопровождение и развитие может и должно начинаться с документирования.
Но они ошибаются.

(25) ты так говоришь, как будто это плохой какой-то метод

(27) для ларька конечно нормальный. для большой системы - абсолютно нет.

хотя в 1с даже у больших компаний мышление ларьков (в основном)

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

(25) Ну Вы как-то поотстали от жизни. Теперь это правильно называется Scrum. Суть та же, но заказчик уверен, что работы ведутся по продвинутой буржуйской технологии, а не абы как.

(31) то, о чем вы говорите, называется не скрум, а технический долг, и с ним в том же скруме борются.
Ну и да, если нет документирования, то должны быть тесты. Если нет документации и тестов - то через пол года при незначительном обновлении прически жопа отвалится.

(28) смотря что с этой большой системой делать

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

(0) Бумажка, висио, ёксель.
Битрикс для задач.

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

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

(0)Тоже бывают такие проблемы..

Может конфу написать под это дело? :) Ты же программист..

(38) СППР уже есть

(37) ок, пруфы в вечернюю студию

(0) Схемы рисую в draw.io

(26) Когда выясняется что 80% нужно было сделать по другому, груз документации оттягивает эту мысль на потом, из-за чего новые слои документации окончательно цементируют сложившуюся модель и все проблемы становятся фичами.

Enterprise Architect

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