UML vs Нафиг

[Wound]

Цитата D_KEY @ 03.07.20, 13:27

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

Ты хотел написать наверное: "ты можешь писать сразу код"? Потому как то что ты написал не имеет никакого отношения к проектированию.

Цитата D_KEY @ 03.07.20, 13:27

используя такие практики, как "стрельба трассирующими" и т.д. и т.п. А есть еще XP. А есть еще TDD, BDD. И даже design by coding.

Смешались в кучу кони, люди... А как эти практики противоречат UML, я не пойму ?

Цитата D_KEY @ 03.07.20, 13:27

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

Да да знаю я, скрам, аджил, как у нас на прошлой работе пилили пилили, сами не знали что они там пилили, потом поняли что cut какая то получилось, начали заного все переделывать
Но даже Agile и всякие scrum - ну никак не противоречат использованию UML, это как бы ортогональные вещи.

Сообщение отредактировано: OpenGL - 03.07.20, 14:24

[D_KEY]

Цитата Wound @ 03.07.20, 13:19

На абстрактном уровне как раз у них много общего.

Расскажи.

Цитата

Цитата D_KEY @ 03.07.20, 13:17

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

Интересно в каком месте когда железо проектируешь, подходит аналогия со строительством? Как раз для софта и подходит.

В том месте, в котором прежде чем паять, тебе нужно спроектировать. Так же, как прежде чем строить, нужно спроектировать.
Софт же - это и есть проект. Смотри, ты можешь нарисовать схему UML, а можешь тоже самое накидать в коде. Это просто разные языки.
Причем если ты это сделаешь в коде, ты уже сможешь накидать тесты. Или вообще написать тесы до, как в TDD.

Цитата

D_KEY, Расскажи как без UML Диаграмм понять что делает система и ее компоненты? Как они взаимосвязаны и как общаются между собой? Может я чего не знаю?
Я просто не представляю как по коду все это анализировать? Расскажи.

Ну берешь код и читаешь (IDE умеют сворачивать блоки и реализации). Так же можно из кода сгенерировать и диаграммы (а не наоборот).

Но все это будет работать, если система нормально спроектирована и код хороший
Чем хуже будет код, чем запутаннее система, тем больше необходимость в диаграммах. В этом и суть моего вброса.

Добавлено 03.07.20, 13:41

Цитата Wound @ 03.07.20, 13:34

Ты хотел написать наверное: "ты можешь писать сразу код"? Потому как то что ты написал не имеет никакого отношения к проектированию.

Имеет. У тебя представления о проектировании где-то из 90х годов прошлого века. Если не из 80х...

Цитата

Смешались в кучу кони, люди... А как эти практики противоречат UML, я не пойму ?

Тебе не нужно проектировать в UML при использовании этих практик.

Цитата

Но даже Agile и всякие scrum - ну никак не противоречат использованию UML, это как бы ортогональные вещи.

Не противоречат. И я ничего не говорил про agile и scrum

Цитата

Да да знаю я, скрам, аджил, как у нас на прошлой работе пилили пилили, сами не знали что они там пилили, потом поняли что cut какая то получилось, начали заного все переделывать

А на что им были sprint review? Или ты про один спринт говоришь? Тогда ок, это нормально. Если же это длительный период, то какой-то странный у тебя был скрам.

Сообщение отредактировано: OpenGL - 03.07.20, 14:24

[Wound]

Цитата D_KEY @ 03.07.20, 13:36

Расскажи.

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

Цитата D_KEY @ 03.07.20, 13:36

В том месте, в котором прежде чем паять, тебе нужно спроектировать. Так же, как прежде чем строить, нужно спроектировать.

А че там, берешь паяльник и паяешь, ровно так же и со строительством.

Цитата D_KEY @ 03.07.20, 13:36

Софт же - это и есть проект. Смотри, ты можешь нарисовать схему UML, а можешь тоже самое накидать в коде. Это просто разные язык.
Причем если ты это сделаешь в коде, ты уже сможешь накидать тесты. Или вообще написать тесы до, как в TDD.

Ну накидай в коде? Я не понимаю. Покажи мне архитектуру ну например apache в виде кода.
Мы может быть о разных вещах говорим? Ты когда в последний раз, скажем незнакомой тебе системе прикручивал новый функционал?

Цитата D_KEY @ 03.07.20, 13:36

Ну берешь код и читаешь (IDE умеют сворачивать блоки и реализации). Так же можно из кода сгенерировать и диаграммы (а не наоборот).

Ну как мне прочитать код, если там 200 проектов, 1000000 классов ? Мне нужно понять как это все работает желательно за вменяемое время.

Цитата D_KEY @ 03.07.20, 13:36

Но все это будет работать, если система нормально спроектирована и код хороший

Покажи пример.

Цитата D_KEY @ 03.07.20, 13:36

Чем хуже будет код, чем запутаннее система, тем больше необходимость в диаграммах. В этом и суть моего вброса.

В каком плане хуже? Если его никто не проектировал, как он может быть лучше и не запутанным?

[D_KEY]

Wound, просто погугли design by coding, почитай, видосики посмотри. Я не призываю конкретно к этой практике, но ты меня лучше будешь понимать.

Добавлено 03.07.20, 13:47
https://www.youtube.com/watch?v=d5Y1B1cmaGQ

[Wound]

Цитата D_KEY @ 03.07.20, 13:36

Имеет. У тебя представления о проектировании где-то из 90х годов прошлого века. Если не из 80х...

Из 60-х же.

Цитата D_KEY @ 03.07.20, 13:36

Тебе не нужно проектировать в UML при использовании этих практик.

Как мне эти практики помогут? Ты можешь нормально расписать?

Цитата D_KEY @ 03.07.20, 13:36

Не противоречат. И я ничего не говорил про agile и scrum

Подразумевал:

Цитата D_KEY @ 03.07.20, 13:27

Эти вещи нацелены на постепенное создание продукта с короткими цепями обратной связи

Или что ты под этим подразумевал, я хз.

Цитата D_KEY @ 03.07.20, 13:36

А на что им были sprint review? Или ты про один спринт говоришь? Тогда ок, это нормально. Если же это длительный период, то какой-то странный у тебя был скрам.

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

[D_KEY]

Цитата Wound @ 03.07.20, 13:45

Все достаточно примитивно, есть фундамент - ядро/утилиты/библиотеки, короче все вот это низкоуровневое говно

Если я применяю DI из SOLID, то это уже не подходит
Опять же, я могу поменять библиотеку из "фундамента" (причем достаточно легко, если нормально спроектирована система) или даже выкинуть ее.
Попробуй поменять или выкинуть кусок фундамента в доме.

[Wound]

Цитата D_KEY @ 03.07.20, 13:46

Wound, просто погугли design by coding, почитай, видосики посмотри. Я не призываю конкретно к этой практике, но ты меня лучше будешь понимать.

Я посмотрел видео на ютубе, которые ты тут запостил - не вижу там как бы это могло заменить UML, или как это даст мне инструмент для анализа незнакомой мне системы, например.
Начал в гугле искать, ниче толкового не нашел. Скинь ссылку на что то более вменяемое, чем ютуб ролик выше.

[D_KEY]

Цитата Wound @ 03.07.20, 13:48

Цитата D_KEY @ 03.07.20, 13:36

Тебе не нужно проектировать в UML при использовании этих практик.

Как мне эти практики помогут? Ты можешь нормально расписать?

Возможно чуть позже.

Цитата

Цитата D_KEY @ 03.07.20, 13:27

Эти вещи нацелены на постепенное создание продукта с короткими цепями обратной связи

Или что ты под этим подразумевал, я хз.

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

Цитата

Цитата D_KEY @ 03.07.20, 13:36

А на что им были sprint review? Или ты про один спринт говоришь? Тогда ок, это нормально. Если же это длительный период, то какой-то странный у тебя был скрам.

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

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

[Wound]

Цитата D_KEY @ 03.07.20, 13:51

Если я применяю DI из SOLID, то это уже не подходит

Еще как подходит. Ты почему то пытаешься какие то детали натянуть на парадигму.
Ну можно сказать еще - если я std::string использую - то это уже не подходит. DI - это всего лишь зависимость, понимаешь? На этапе понимания принципа работы системы - даже не важно какая это зависимость, пришедшая из вне или косвенная какая нибудь, наследование или агрегирование.

Цитата D_KEY @ 03.07.20, 13:51

Опять же, я могу поменять библиотеку из "фундамента" (причем достаточно легко, если нормально спроектирована система) или даже выкинуть ее.
Попробуй поменять или выкинуть кусок фундамента в доме.

Фундамент так же бывает плывет, даже бывает его чинят и переделывают, укрепляют и т.д.
Ты в курсе что в Москве уже построенные здания передвигали в 1930-х? https://moslenta.ru/city/doma.htm
А ты тут пишешь про то, что кусок фундамента поменять невозможною.

[D_KEY]

Цитата Wound @ 03.07.20, 13:53

не вижу там как бы это могло заменить UML, или как это даст мне инструмент для анализа незнакомой мне системы

Это два разных вопроса. UML как инструмент для проектирования, и UML, как инструмент для изучения. Во втором случае ты можешь сгенерировать UML из уже существующего кода.
Или же сам его составить в качестве документации.

[Wound]

Цитата D_KEY @ 03.07.20, 13:58

Это два разных вопроса. UML как инструмент для проектирования, и UML, как инструмент для изучения. Во втором случае ты можешь сгенерировать UML из уже существующего кода.
Или же сам его составить в качестве документации.

Ну это как генерировать план здания после его постройки.
Я под UML, если что, понимаю стандарт для моделирования неких систем, а не конкретную какую то программу.
Когда ты из кода генерируешь схему - это значит, что ты хочешь посмотреть что у тебя получилось, но это не относится к проектированию. К проектированию будет относится, когда ты сам будешь осознанно рисовать диаграмму или вносить изменения в уже существующую.
Из уже существующего кода как правило ты можешь сгенерировать что то примитивное, которое не даст тебе полной ясности, плюс такая схема будет содержать в себе 90% мусора, и 10% полезной инфы. Ну и например какие нибудь внешние зависимости оно тебе либо нарисует на примитивном уровне, либо не нарисует вовсе.

Сообщение отредактировано: Wound - 03.07.20, 14:06

[D_KEY]

Цитата Wound @ 03.07.20, 13:57

Цитата D_KEY @ 03.07.20, 13:51

Если я применяю DI из SOLID, то это уже не подходит

Еще как подходит.

Не подходит. В случае DI у тебя нет фундамента, у тебя части системы зависят от интерфейсов, а не "стоят" друг на друге.

Добавлено 03.07.20, 14:06

Цитата Wound @ 03.07.20, 14:04

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

Я ровно это и написал, когда сказал, что это два разных вопроса - проектирование и понимание системы.

Добавлено 03.07.20, 14:08

Цитата Wound @ 03.07.20, 14:04

Ну это как генерировать план здания после его постройки.

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

Добавлено 03.07.20, 14:11

Цитата Wound @ 03.07.20, 14:04

Из уже существующего кода как правило ты можешь сгенерировать что то примитивное, которое не даст тебе полной ясности, плюс такая схема будет содержать в себе 90% мусора, и 10% полезной инфы.

И вот тут мы возвращаемся к моему изначальному тезису. Для хорошо спроектированной системы, сгенерированная схема будет понятной и полезной. Если у тебя 90% мусора в схеме, то это значит, что это в системе твоей так и в коде.

[Wound]

Цитата D_KEY @ 03.07.20, 14:05

Не подходит. В случае DI у тебя нет фундамента, у тебя части системы зависят от интерфейсов, а не "стоят" друг на друге.

Я же говорю, ты смешиваешь в кучу какие то детали реализации. Причем тут фундамент и DI ? DI - это всего лишь внедрение какой то внешней зависимости, каким либо способом. В любой схеме есть зависимости. При любом подходе есть зависимости. У тебя, когда ты строишь здание так же выбор цемента/материала для создания фундамента от чего то зависит. Я не понимаю причем тут все это?
Как cut, DI противоречит UML ? Или как оно противоречит аналогии строительства дома?
Вот есть у тебя дом, в нем есть мебель, как она туда попала из магазина? Не через DI ?
Как нет фундамента? То же ядро и является фундаментом. Весь библиотечный код, практически все вот эти паттерны и являются фундаментом.

Цитата D_KEY @ 03.07.20, 14:05

Я ровно это и написал, когда сказал, что это два разных вопроса - проектирование и понимание системы.

Где ты что написал? Зачем ты тогда привел генерирование диаграммы иерархии классов из кода?

Добавлено 03.07.20, 14:18

Цитата D_KEY @ 03.07.20, 14:05

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

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

Цитата D_KEY @ 03.07.20, 14:05

И вот тут мы возвращаемся к моему изначальному тезису. Для хорошо спроектированной системы, сгенерированная схема будет понятной и полезной. Если у тебя 90% мусора в схеме, то это значит, что это в системе твоей так и в коде.

В 99% случаев не будет. А в 1% там просто будет мало кода.

Добавлено 03.07.20, 14:21
Да и зачем генерировать диаграмму классов из исходников? Ведь наличие UML Диаграммы говорит о том что система плохо спроектирована, ну по твоему.

Добавлено 03.07.20, 14:31
Да и к слову сейчас набирают обороты всякие микросервисные системы, программные компоненты пишутся на разных языках даже в раммках одного проекта, как тут без диаграм что то понять?
Нет, если ты всю свою жизнь пишешь на С++, сидишь 15 лет в одной конторе, в которой ты уже этот программный продукт без всяких схем знаешь, и фиксишь какие нибудь там баги, изредка прикручивая какие то отдельные не зависимые модули. То тебе в принципе UML нахрен не нужен.
А мне он нужен. У меня вот сейчас один небольшой проект уже вылился в использования 2-3 разных ЯП, разных модулей, и это все еще нужно прикрутить к системе. Благо из нее торчит только 1 нужный интерфейс. Но даже для этого мы начинали с блоксхем. Как оно будет взаимодействовать, что от чего будет зависеть и т.д. Потому что сгенерировать схему из кода, которого у тебя нет, сложно. А иметь представление как это должно взаимодействовать между собой - нужно.

Добавлено 03.07.20, 14:45
Попробуй без UML диаграм объяснить людям что должна делать система, как она должна взаимодействовать с другими компонентами, от чего она должна быть зависима и т.д. В итоге ты придешь к тому, что начнешь рисовать UML диаграммы, пусть и не по стандарту UML.

Вот тебе: https://docs.microsoft.com/ru-ru/windows/wi...dentialprovider интерфейс виндового логин провайдера. Ты можешь по этому интерфейсу рассказать принцип его работы? Да нет конечно. Вангую ты будешь в этом дерьме неделю разбираться и не факт что поймешь без пол литры что то.
А вот блоксхема:
https://docs.microsoft.com/ru-ru/windows-se...-authentication

Скрытый текст

И сразу становится понятен общий механизм логина пользователя в систему.

Добавлено 03.07.20, 14:56
Допустим на замену UML можно взять Doxygen или что то подобное, там оно генерирует какие то примитивные блоксхемы. Но опять же это слишком детализировано, и как правило много мусора и лишней инфы в такой иерархии. UML - это как телескоп, через который ты наблюдаешь отдаленную галактику и понимаешь ее структуру, тебе не важна одна конкретная какая то звездная система, ты наблюдаешь всю галактику целиком.
Опять же нужно - приблизил - получил какую нибудь структуру звездной системы, потому что тебя интересует структура этой звездной системы, а не какая там атмосфера на какой либо планете.

Сообщение отредактировано: OpenGL - 03.07.20, 14:56

[korvin]

Цитата D_KEY @ 03.07.20, 13:27

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

Или полную херню, а не архитектуру, потому что слишком много «ad-hoc» решений. =)

А UML — говно и не нужно, да.

[D_KEY]

Цитата korvin @ 03.07.20, 16:22

Цитата D_KEY @ 03.07.20, 13:27

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

Или полную херню, а не архитектуру, потому что слишком много «ad-hoc» решений. =)

Ну это зависит уже от способностей людей, не от подхода
Гораздо хуже будет, если ты будешь все заранее продумывать, а потом в середине или к концу проекта придется требования менять. Так что если есть такие риски (а они сейчас почти всегда есть), лучше больше обратной связи собирать, fail fast и все такое.