На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (4) 1 [2] 3 4  все  ( Перейти к последнему сообщению )  
> UML vs Нафиг
   
пользуете ли вы это в своей деятельности?
Гости не могут просматривать результаты голосования.
Гости не могут голосовать 
    Цитата D_KEY @
    Я тоже когда-то так думал, но это ошибочная точка зрения. Ты можешь проектировать сразу в код. Прототипируя, командно обсуждая интерфейсы(прямо через PR в коде, а не в схемах),

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

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

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

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

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

      Расскажи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

          Добавлено
          https://www.youtube.com/watch?v=d5Y1B1cmaGQ
            Цитата D_KEY @
            Имеет. У тебя представления о проектировании где-то из 90х годов прошлого века. Если не из 80х...

            Из 60-х же.

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

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


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

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

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

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

            Они делали что то абстрактное, вот как раз как ты тут пишешь, короче делали то, не знаю че. Небыло у них понимания что они хотели получить в конце.
              Цитата Wound @
              Все достаточно примитивно, есть фундамент - ядро/утилиты/библиотеки, короче все вот это низкоуровневое говно

              Если я применяю DI из SOLID, то это уже не подходит ;)
              Опять же, я могу поменять библиотеку из "фундамента" (причем достаточно легко, если нормально спроектирована система) или даже выкинуть ее.
              Попробуй поменять или выкинуть кусок фундамента в доме.
                Цитата D_KEY @
                Wound, просто погугли design by coding, почитай, видосики посмотри. Я не призываю конкретно к этой практике, но ты меня лучше будешь понимать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                            user posted image

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

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

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

                              А UML — говно и не нужно, да.
                                Цитата korvin @
                                Цитата D_KEY @
                                что позволяет и продукт делать нужный и архитектуру иметь заточенную под реальность, а не под фантазии архитектора.

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

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


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0729 ]   [ 17 queries used ]   [ Generated: 4.02.23, 22:27 GMT ]