На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS

Поздравляем всех студентов и Татьян с Татьяниным днём!




msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
  
> UML vs Нафиг
   
пользуете ли вы это в своей деятельности?
Гости не могут просматривать результаты голосования.
Гости не могут голосовать 
    Буэнос диас, амигос!

    Хочется похоливарить на тему сабжа ;) А, если честно, очень хочется услышать true history как жысть резко наладилась, когда началось скучное и повседневное использование UML при проектировании и документировании, прямо кушать не могу. Истории горьких разочарований и лютой досады - интересуют также.
      Ответил "не пользуюсь", хотя до ссылки на вики даже не знал, что это такое. Теперь хоть почитаю... Почитал. Очередное "программирование мышкой"? Не, нафиг.
        Цитата Dushevny @
        Почитал. Очередное "программирование мышкой"? Не, нафиг.

        Это просто ты с большими проектами, видимо, еще не сталкивался. Очень незаменимая вещь, для понимания как что взаимосвязано и как работает. Эта штука нужна в основном архитекторам, для написания блок схем программы, чтобы наглядно показать как и что взаимосвязано в системе. Программисту эта штука так же может понадобиться для того, чтоб посмотреть как взаимосвязаны сущности между собой.
        Уверен практически любой программист рисовал UML диаграммы в тетрадке, ну если сталкивался хотя б с 10+ взаимосвязанных классов.
        Так что это не очередное "программирование мышкой", а очень востребованный продукт.

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

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

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

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

        Добавлено
        Ну и к слову еще: Для объяснения тех же патернов проектирования активно используются UML-диаграммы.
        https://ru.wikipedia.org/wiki/%D0%9F%D1%80%...BD%D0%B8%D1%8F)

        https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%...BD%D0%B8%D1%8F)

        Глядя на UML-диаграмму сразу становится понятен принцип работы патерна. Попробуй сразу же так понять принцип работы глядя на код. А если он еще и не просто голвый, а со всякими наворотами и неявными связями?
        Сообщение отредактировано: Wound -
          Wound, я почему поднял эту нему - тупо начал "плавать" в сигналах-слотах своей проги (Qt5/C++). Ладно было бы связать стопицот созданных объектов, и существующих до конца выполнения проги ... Так около 20% объектов получились динамическими (создание-выполнение-разрушение). Началось разрушение моего мозга. И вот вспомнил то, что когда-то надежно забыл.
            Цитата JoeUser @
            Просто проголосуй, а лучше и коммент по теме оставь.

            Да особо нечего расписывать. Взаимодействие между частями крупной системы так или иначе нужно описывать, т.к. у тебя в коде нет одного места, где бы ты мог крупномасштабно увидеть, что у тебя происходит. UML это будет или просто текстовый документ - не сильно, в общем-то важно. Лично мне uml как-то не зашёл, но это субъективщина.
              Цитата OpenGL @
              UML это будет или просто текстовый документ

              Не не не !!! В спецификации - куча видов диаграмм, отвечающих за разные аспекты проектирования. Там может быть много чего - и взаимодействие, и иерархия, и таймлайн ... много чего. Каждый вид диаграммы описывает свое свойство (а если вернее - "предназначение"). Как бы я не сопротивлялся "дополнительному" - сска, чувствую учить и использовать надо. Особенно когда проектируемая система выходит за "10 классов" © Киля. А может и раньше надо.
                Цитата JoeUser @
                Как бы я не сопротивлялся "дополнительному" - сска, чувствую учить и использовать надо.

                Ну а почему нет? Это просто инструмент, а уж как ты его будешь использовать - дело твоё
                  Цитата OpenGL @
                  UML это будет или просто текстовый документ - не сильно, в общем-то важно. Лично мне uml как-то не зашёл, но это субъективщина.

                  Ну UML это просто как бы стандрат. Для себя можно рисовать хоть в блокноте, хоть в паинте. А если показывать кому то - то нужно юзать UML, чтоб тот, другой понял. Иначе тебе придется отдельно расписывать где какой блок что означает, где какая стрелка что означает. Как наследование отличить от агрегирования, где нарисован класс, а где компонент и т.д.

                  В студии есть встроенные средства для генерирования связей, что то типа UML диаграммы, но не по стандарту UML. Но там в динамике все. Можно мышкой навести и глянуть где что обозначает.
                    Цитата OpenGL @
                    Ну а почему нет?

                    Ну я на бессознательном - всегда пользую Бритву Оккамы.
                    Поэтому каждые "дополнительные новшества" у меня проходят строгую проверку на предмет измены родине :lol:
                      Использую иногда диаграммы классов, реже диаграммы последовательности. Остальное почти не использую.

                      На правах вброса: чем хуже система спроектирована, тем больше необходимы диаграммы :)
                        Цитата D_KEY @
                        На правах вброса: чем хуже система спроектирована, тем больше необходимы диаграммы

                        Ну да. Это как с постройкой дома. Если есть полный план строительства - значит плохо спроектировали(иначе нахрена нам план?). Если нет, значит хорошо спроектирован :lol:
                        Я бы наверное даже твою фразу перефразировал. Если сначало написали систему, а UML диаграм еще нет - значит никто ничего не проектировал, просто написали по велению левой пятки, и скорее всего оно плохо спроектировано(вернее оно даже не спроектировано, а просто тупо написано абы как). А если UML диаграмма появилась до написания системы. Значит систему сидели и проектировали, а уж потом начали писать по предварительно разработанному плану/архитектуре.

                        Вообще где не работал(ну достаточно большие конторы), везде использовались UML диаграммы. Есть спецификации, UML диаграммы классов, компонентов, все это как правило входит в техническую литературу системы.
                        Если этих диаграм нет, значит систему проектировали на коленке, и как правило в ней куча косяков, подводных камней и неучтенных концептуальных ошибок.

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

                        Вот устроился я на новую работу, они там разрабатывают программу, в которую входит целая куча компонентов, 100500 файлов, кода, библиотек, включая сторонних.

                        Мне говорят, вот у нас есть вся эта лабуда, надо короче в внести изменения в систему, чтоб она умела работать в режиме NLB кластера. Иииии? Что ты будешь делать без диаграмм с офигенно спроектированной системой?
                        Вангую что ты будешь сидеть неделю, и рисовать эти UML диаграммы анализируя код, чтоб понять как оно вообще работает, какие модули будут затронуты, и т.д.
                        Сообщение отредактировано: Wound -
                          Цитата Wound @
                          Ну UML это просто как бы стандрат.

                          Да неважно. Я именно о предпочитаемом представлении данных говорю. Показать иерархию классов ещё куда ни шло, но, например, показывать, как у меня идут данные между сервисами - ну нахрен, я лучше ту же информацию прочитаю текстом, и текстом же опишу это в ТЗ.
                            Цитата Wound @
                            Ну да. Это как с постройкой дома.

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

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

                            Добавлено
                            Если попытаться улучшить аналогию, то создание софта является скорее созданием проекта дома, а не самого дома. Сам дом ты получаешь, когда build делаешь :)
                            Сообщение отредактировано: D_KEY -
                              Цитата OpenGL @
                              Да неважно. Я именно о предпочитаемом представлении данных говорю. Показать иерархию классов ещё куда ни шло, но, например, показывать, как у меня идут данные между сервисами - ну нахрен, я лучше ту же информацию прочитаю текстом, и текстом же опишу это в ТЗ.

                              Нет, ну упарываться конечно не стоит. Есть же всякие стандарты/сервисы/протоколы(XML/json/SOAP/REST) это все можно просто абстрактно записывать.
                              Типа есть компонент А, есть компонент B, B зависит от A, на стрелке пишешь REST/json, или там SOAP/xml, сразу становится понятно что данные передаются посредством такого то протокола в таком то формате.

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

                              Но просто ты когда себе что пишешь - ты то понимаешь, а допустим если тебе это нужно отдать следующим разрабам, то как им понять где что? Проще нафигачить UML диаграмму. Но опять же - в основном этим занимаются архитекторы, ибо это им приходится выдавать документацию по системе, и показывать как что там спроектировано или как нужно делать.

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

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

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

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

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

                              Цитата D_KEY @
                              Если попытаться улучшить аналогию, то создание софта является скорее созданием проекта дома, а не самого дома. Сам дом ты получаешь, когда build делаешь

                              :facepalm: Ты спустился на какой то ассемблерный уровень и от туда рассуждаешь об абстрактных UML диаграммах.

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

                              Добавлено
                              Даже примитивным паттернам проектирования рисуют диаграммы, чтоб быстрее пришло понимание основного принципа работы.
                              Потому что на диаграмму посмотрел - и сразу все стало понятно. А по коду надо сидеть неделю разбираться и рисовать все те же диаграммы, пусть и не в UML стандарте.
                              Сообщение отредактировано: Wound -
                                Цитата Wound @
                                Я бы наверное даже твою фразу перефразировал. Если сначало написали систему, а UML диаграм еще нет - значит никто ничего не проектировал, просто написали по велению левой пятки, и скорее всего оно плохо спроектировано(вернее оно даже не спроектировано, а просто тупо написано абы как).

                                Я тоже когда-то так думал, но это ошибочная точка зрения. Ты можешь проектировать сразу в код. Прототипируя, командно обсуждая интерфейсы(прямо через PR в коде, а не в схемах), используя такие практики, как "стрельба трассирующими" и т.д. и т.п. А есть еще XP. А есть еще TDD, BDD. И даже design by coding.
                                Эти вещи нацелены на постепенное создание продукта с короткими цепями обратной связи, что позволяет и продукт делать нужный и архитектуру иметь заточенную под реальность, а не под фантазии архитектора.
                                Сообщение отредактировано: D_KEY -
                                  Цитата 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 и все такое.
                                                                Цитата D_KEY @
                                                                Ну это зависит уже от способностей людей, не от подхода
                                                                Гораздо хуже будет, если ты будешь все заранее продумывать, а потом в середине или к концу проекта придется требования менять. Так что если есть такие риски (а они сейчас почти всегда есть), лучше больше обратной связи собирать, fail fast и все такое.

                                                                Но опять же, это смотря что разрабатываешь, «mission critical» софт обычно имеет чёткие, строгие и полностью заранее известные требования.

                                                                И не обязательно прям всё продумывать. Проблема во всех этих agile методологиях в том, что бизнесу часто не интересен рефакторинг совсем, типа сделал фичу — делай следующую, в результате имеем нагромождение костылей и говнокода вместо адаптации архитектуры, оптимизации алгоритмов и т.п.
                                                                  Цитата D_KEY @
                                                                  Ну это зависит уже от способностей людей, не от подхода

                                                                  Да да расскажи плиз, как писать сложную систему(комплекс различных модулей, которые будут взаимодействовать между собой) с нуля, команде разрабов, без диаграмм? Ты помниться обещался рассказать позже, но видимо забыл?

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

                                                                  Зачем продумывать все? Вот как раньше софт писали, налабали какой нибудь WinAmp там или тот же Far, круто есть программулина, но что если люди захотят другой функционал, какой нибудь такой которого нет, или изменить существующий? Это решается очень просто - моды/плагины. Вплоть до смены внешнего вида и поведения. И ниче, ничего не нужно было менять и переписывать. А сейчас повсеместно поди требования меняют и переписывают там что то.
                                                                  А что ты будешь делать если у тебя несколько крупных заказчиков требуют разный функционал, порой даже противоречивый?

                                                                  Добавлено
                                                                  Цитата korvin @
                                                                  бизнесу часто не интересен рефакторинг совсем

                                                                  Бизнесу не интересен рефакторинг в принципе, ну за исключением самой конторы-разработчика.
                                                                  Сообщение отредактировано: Wound -
                                                                    Цитата Wound @
                                                                    Бизнесу не интересен рефакторинг в принципе, ну за исключением самой конторы-разработчика.

                                                                    Не знаю, что ты подразумеваешь под «бизнесом», но я имел в виду в том числе и компании, разрабатывающие софтварный продукт, тысячи их.
                                                                      Цитата korvin @
                                                                      Не знаю, что ты подразумеваешь под «бизнесом», но я имел в виду в том числе и компании, разрабатывающие софтварный продукт, тысячи их.

                                                                      Ну я думал ты про заказчиков пишешь. Заказчикам рефакторинг нафиг не уперся, компаниям - которые разрабатывают ПО, тут да, это актуально.
                                                                        Цитата korvin @
                                                                        Но опять же, это смотря что разрабатываешь, «mission critical» софт обычно имеет чёткие, строгие и полностью заранее известные требования.

                                                                        Нет, кстати. Там обычно есть стандарты и пр., но по одному и тому же стандарту можно сделать совершенно разные продукты, которые будут им соответствовать ;)

                                                                        Добавлено
                                                                        Цитата korvin @
                                                                        И не обязательно прям всё продумывать. Проблема во всех этих agile методологиях в том, что бизнесу часто не интересен рефакторинг совсем, типа сделал фичу — делай следующую, в результате имеем нагромождение костылей и говнокода вместо адаптации архитектуры, оптимизации алгоритмов и т.п.

                                                                        Это проблема коммуникаций. Если речь конкретно про скрам, то коммуникаций между командой разработки и владельцем продукта. Я такое видел и видел, как это решается :)

                                                                        Добавлено
                                                                        Цитата Wound @
                                                                        Да да расскажи плиз, как писать сложную систему(комплекс различных модулей, которые будут взаимодействовать между собой) с нуля, команде разрабов, без диаграмм?

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

                                                                        Как я рекомендовал бы действовать? Сформировать видение продукта, затем можно использовать impact mapping и story mapping, сформировать MVP.
                                                                        Опираясь на это, спроектировать гибкий каркас системы, я бы использовал подход C4(без последней C) в сочетании с рассмотрением рисков(совместно с разработчиками и бизнесом) на каждом шаге. Далее уже идем итеративно и инкрементально, делаем небольшую систему, опираясь на хорошие инженерные практики и принципы (от шаблонов проектирования, *DD до CI/CD) и создаем себе инфраструктуру для быстрой разработки с тестами на всех уровнях, код ревью и пр., и на каждой итерации наращиваем продукт, опираясь на обратную связь от пользователей, заказчиков и пр., показывая или уже поставляя продукт после каждой итерации. Общее требование к архитектуре - гибкость (по факту, если следовать хорошим практикам и принципам, то она будет). Остальное уже в зависимости от продукта.

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

                                                                          Нет, они такие же заказчики, точнее их клиенты, ПО пишется не просто так, а для кого-то/чего-то, в случае софтверной компании (даже таких чисто софтверных, как JetBrains, например), есть клиенты/пользователи/рынок/конкуренты, которых можно назвать «заказчиками».

                                                                          Цитата D_KEY @
                                                                          Нет, кстати. Там обычно есть стандарты и пр., но по одному и тому же стандарту можно сделать совершенно разные продукты, которые будут им соответствовать

                                                                          Кроме стандартов есть требования к реализации (те же системы реального времени и т.п., думаю тут Qraizer может рассказать, например).

                                                                          Цитата D_KEY @
                                                                          Это проблема коммуникаций.

                                                                          Нет, это проблема самого подхода: на каждом этапе скоуп ограничен, особенно временными рамками. Нельзя при решении небольшой задачи проводить повсеместный рефакторинг, например, даже если он выглядит очень полезным. Задача уже оценена по времени/усилиям и вообще при заявлении, что «тут нужно подрефакторить всё и это займёт в 5 раз больше времени, чем простое решение», тебя пошлют нахрен, потому что коллега оценит решение этой задачи как требующее в пять раз меньше времени, чем ты оценил (с рефакторингом), то руководство посчитает, что ты неэффективный мудак, а твой коллега — настоящий профессионал, независимо от того, насколько говнокодное будет его решение и насколько высок окажется тех.долг, главное, что он задачу решил быстрее.
                                                                            Цитата D_KEY @
                                                                            Я такое видел и видел, как это решается :)

                                                                            Частные подробности могу при встрече рассказать. А в общих чертах, PO обязательно должен понимать, что мы вставляем костыли и что за это нужно заплатить потом. Т.е. приходит он с какой-то бизнес задачей(user story или еще чего), команда дает оценки и прогноз, когда сделает. Если уже тут команда снижает оценку и костылит, то проблема в команде и ее ответственности за качество. Если же прогноз дан с учетом нормально сделанного решения и PO согласен, то все должно быть ок. Если же PO говорит, что пипец как срочно, сделайте плиз раньше, то начинается торг. Мы можем убрать часть требований, если это позволит быстрее сделать без потери качества, а можем решить, что сейчас сделаем прототип или костыль вставис, но тут же в бэклог заносим пункт на создание нормального решения и обсуждаем, когда нужно.
                                                                            Нормальный PO понимает(а если нет, можно объяснить), что костыли рано или поздно приведут к тому, что мы или замедлимся или вообще не сможем делать нужные фичи впоследствии.

                                                                            Добавлено
                                                                            Цитата korvin @
                                                                            Цитата D_KEY @
                                                                            Нет, кстати. Там обычно есть стандарты и пр., но по одному и тому же стандарту можно сделать совершенно разные продукты, которые будут им соответствовать

                                                                            Кроме стандартов есть требования к реализации (те же системы реального времени и т.п., думаю тут Qraizer может рассказать, например).

                                                                            Все верно, но ты всё равно можешь сделать очень разные продукты, которые будут соответствовать этим внешним требованиям. Их обязательно нужно учитывать и такая ситуация даже проще в плане проектирования, чем когда таких ограничений нет.
                                                                              Цитата korvin @
                                                                              Нет, они такие же заказчики, точнее их клиенты, ПО пишется не просто так, а для кого-то/чего-то, в случае софтверной компании (даже таких чисто софтверных, как JetBrains, например), есть клиенты/пользователи/рынок/конкуренты, которых можно назвать «заказчиками».

                                                                              Ну ок, тут ты прав, софтварные конторы(заказчики) для которых пишут другие софтварных конторы - я как то не учел.
                                                                              Сообщение отредактировано: Wound -
                                                                                Цитата korvin @
                                                                                Цитата D_KEY @
                                                                                Это проблема коммуникаций.

                                                                                Нет, это проблема самого подхода

                                                                                Смотри выше. Я видел, когда такая проблема была и как она ушла после фикса проблем в коммуникации.

                                                                                Добавлено
                                                                                Цитата korvin @
                                                                                Задача уже оценена по времени/усилиям и вообще при заявлении, что «тут нужно подрефакторить всё и это займёт в 5 раз больше времени, чем простое решение», тебя пошлют нахрен, потому что коллега оценит решение этой задачи как требующее в пять раз меньше времени, чем ты оценил (с рефакторингом), то руководство посчитает, что ты неэффективный мудак, а твой коллега — настоящий профессионал, независимо от того, насколько говнокодное будет его решение и насколько высок окажется тех.долг, главное, что он задачу решил быстрее.

                                                                                То, что ты тут описал противоречит agile подходу :)
                                                                                У тебя в agile независимые и самостоятельные команды, принимающие решения об объеме работ, которые они берут в итерацию.
                                                                                Если это не так, то у тебя не agile и тогда говорить нужно о другом.
                                                                                  Цитата D_KEY @
                                                                                  Все верно, но ты всё равно можешь сделать очень разные продукты, которые будут соответствовать этим внешним требованиям. Их обязательно нужно учитывать и такая ситуация даже проще в плане проектирования, чем когда таких ограничений нет.

                                                                                  Ага, но проектирование тут всё равно идёт сильно вперёд, и оно более скурпулёзное, нельзя просто взять и agile'овски сказать: а давайте сделаем вот так, потом посмотрим, что будет, проанализируем реакцию пользователей, т.к. какой-нибдь томограф может выжечь пациенту мозг (или типа того, я утрирую, но думаю, ты понял)

                                                                                  Цитата D_KEY @
                                                                                  Я видел, когда такая проблема была и как она ушла после фикса проблем в коммуникации.

                                                                                  Вот у нас подумывают взять скрам-мастера в команду, пойдёшь? (P.S. есть код на плюсах, если что)

                                                                                  Цитата D_KEY @
                                                                                  То, что ты тут описал противоречит agile подходу
                                                                                  У тебя в agile независимые и самостоятельные команды, принимающие решения об объеме работ, которые они берут в итерацию.

                                                                                  Нет, не противоречит, ибо «сверху» всегда навязываются минимальные сроки, а «снизу» пытаются «выторговать» более комфортные сроки. Может, это и не agile, но это то, во что этот «agile» вырождается на практике.
                                                                                    Пруфы противоречий.
                                                                                    3 из 12 принципов agile (можно обнаружить на сайте манифеста):
                                                                                    Цитата
                                                                                    Build projects around motivated individuals.
                                                                                    Give them the environment and support they need,
                                                                                    and trust them to get the job done.

                                                                                    ...

                                                                                    Continuous attention to technical excellence
                                                                                    and good design enhances agility.

                                                                                    ...

                                                                                    The best architectures, requirements, and designs
                                                                                    emerge from self-organizing teams.


                                                                                    Добавлено
                                                                                    Цитата korvin @
                                                                                    Может, это и не agile, но это то, во что этот «agile» вырождается на практике.

                                                                                    У нас разная практика :-?
                                                                                    У меня другой опыт, я видел то, о чем пишу.
                                                                                    Пункты из принципов я привел. Могу из scrum гайда еще привести.
                                                                                      Цитата D_KEY @
                                                                                      Создавать нужно продукты, которые решают проблемы пользователей или другого бизнеса, а не "сложные системы" - это уже средство для этого. Насмотрелся я на overengineering в своей жизни...

                                                                                      D_KEY, ну хватит. Ну хватит вот это отходить от темы и писать про какие то проблемы каких то пользователей.
                                                                                      Давай уточним, система например как 1С Предприятие - это сложная система? Система например как 3D Studio Max - это сложная истема? это же всего лишь программы. Хорошо, вот тут выше упомянули JetBrains, давай возьмем тот же IntelliJ IDEA - это сложнная система? Давай еще для сравнения возьмем например этот форум - это сложная система? Ну и для пущего эффекта возьмем например - игру "Волк ловит яйца в корзину", которую можно скачать на Google Play, это сложная система?
                                                                                      Ясный перец с менеджментской точки зрения речь будет идти о продуктах. Но мы же не менеджмент, правда? Мы разрабы, а значит речь идет о системах.
                                                                                      Я не знаю на что ты там насмотрелся, но с моей точки зрения в IT мире существует огромное множество сложных систем, под сложной системой я подразумеваю некий набор компонентов, которые взаимодействуют между собой как то там. Вот и все.

                                                                                      Цитата D_KEY @
                                                                                      Как я рекомендовал бы действовать? Сформировать видение продукта, затем можно использовать impact mapping и story mapping,

                                                                                      Можно нормально, без вот этих вот ваших true story, sad but true, etc. Мы все такие на российском форуме общаемся как бы.
                                                                                      И по подробне раскажи про "сформировать видение продукта"? Как это будет происходить?

                                                                                      К тебе приходит заказчик, говорит мне нужна вот такая вот система, с такими вот параметрами, и уметь она должна это вот это и это, заказчик шарит в теме, он ни какой то холуй, которого можно загрузить вот этими "impact mapping" и "true story", он знает что хочет получить дает тебе ТЗ написанное в общих чертах что и как, ясный перец без описания интерфейсов и всяких программных сущностей, он как бы не по этим делам. Ну и? Твои действия?


                                                                                      Цитата D_KEY @
                                                                                      Опираясь на это, спроектировать гибкий каркас системы, я бы использовал подход C4(без последней C) в сочетании с рассмотрением рисков(совместно с разработчиками и бизнесом) на каждом шаге.

                                                                                      Вот как раз в этом и вопрос - как спроектировать гибкий каркас системы, не взглянув на задачу прищурившись из далека? Расскажи секрет плиз ))

                                                                                      Цитата D_KEY @
                                                                                      Далее уже идем итеративно и инкрементально, делаем небольшую систему, опираясь на хорошие инженерные практики и принципы (от шаблонов проектирования, *DD до CI/CD) и создаем себе инфраструктуру для быстрой разработки с тестами на всех уровнях, код ревью и пр., и на каждой итерации наращиваем продукт, опираясь на обратную связь от пользователей, заказчиков и пр., показывая или уже поставляя продукт после каждой итерации. Общее требование к архитектуре - гибкость (по факту, если следовать хорошим практикам и принципам, то она будет). Остальное уже в зависимости от продукта.

                                                                                      Это уже реализация, но как ты людям все это объяснишь что надо делать? Представь что ты пошел вот от команды как архитектор и тимлид, тебе все расписали, рассказали, ты предложил какие то обходные пути и решения, в итоге вы на чем то там сошлись, ты все это для себя зафикисровал, теперь тебе нужно рассказать разрабам - че делаем, как это ожидается выглядеть, че там есть и все такое. Ты как им это все будешь объяснять? Я так понимаю портянку кода напишешь - нати курите, дальше сами? Или блок-схемы начнешь рисовать на доске?
                                                                                      Сообщение отредактировано: Wound -
                                                                                        D_KEY, давай начнём с того, что это не «принципы», а «рекомендации», «подсказки», которые вывели для себя эти уважаемые люди, что не означает автоматически их абсолютность и уместность применения везде и всюду.

                                                                                        Ну вот из перечисленных тобой ни один не соблюдается на практике. Потому что бизнесу не интересен _этот_ agile, ему интересно только увеличение скорости delivery.
                                                                                          Цитата korvin @
                                                                                          Ага, но проектирование тут всё равно идёт сильно вперёд, и оно более скурпулёзное, нельзя просто взять и agile'овски сказать: а давайте сделаем вот так, потом посмотрим, что будет, проанализируем реакцию пользователей, т.к. какой-нибдь томограф может выжечь пациенту мозг (или типа того, я утрирую, но думаю, ты понял)

                                                                                          У тебя у любой фичи практически будет mission critical часть и нет.
                                                                                          Если это не так, если ты руководствуешься только такими требованиями и нет никаких продуктовых гипотез, то тебе не нужен никакой agile.
                                                                                            Цитата D_KEY @
                                                                                            У нас разная практика
                                                                                            У меня другой опыт, я видел то, о чем пишу.
                                                                                            Пункты из принципов я привел. Могу из scrum гайда еще привести.

                                                                                            Видимо, разная. Я пока наблюдаю гонку за фичами. И вообще за скоростью.
                                                                                              Цитата korvin @
                                                                                              Ну вот из перечисленных тобой ни один не соблюдается на практике.

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

                                                                                              Добавлено
                                                                                              Цитата korvin @
                                                                                              Потому что бизнесу не интересен _этот_ agile, ему интересно только увеличение скорости delivery.

                                                                                              Так следование этим принципам как раз и позволяет надежно и стабильно быстро поставку осуществлять.
                                                                                              Ценность рефакторинга для бизнеса в том, чтобы у нас не было замедления работы или тяжелого внезапного фейла, когда очередная фича развалит все костыли. И это надо до бизнеса доносить.
                                                                                              Сообщение отредактировано: D_KEY -
                                                                                                Цитата D_KEY @
                                                                                                У тебя у любой фичи практически будет mission critical часть и нет.

                                                                                                Эм, нет. Под «mission critical» понимают определённые сферы/области применения софта (это устойчивый термин, насколько я знаю), обычно прямо связанные с человеческими жизнями/здоровьем.

                                                                                                Как там быстро и качественно отображается рекламный баннер на сайте — это не mission critical, как там быстро трейдинговый софт отображает котировки — это не mission critical, мобильное приложение банка (да и весь бэк банка, несмотря на то что обрабатывает реальные и большие деньги) — это не mission critical.

                                                                                                А ПО для мед.оборудования, для космических аппаратов, атомных станций и т.п. — это mission critical
                                                                                                  Цитата korvin @
                                                                                                  Цитата D_KEY @
                                                                                                  У нас разная практика
                                                                                                  У меня другой опыт, я видел то, о чем пишу.
                                                                                                  Пункты из принципов я привел. Могу из scrum гайда еще привести.

                                                                                                  Видимо, разная. Я пока наблюдаю гонку за фичами. И вообще за скоростью.

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

                                                                                                  Добавлено
                                                                                                  Цитата korvin @
                                                                                                  Эм, нет. Под «mission critical» понимают определённые сферы/области применения софта (это устойчивый термин, насколько я знаю), обычно прямо связанные с человеческими жизнями/здоровьем.

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

                                                                                                  И в нем как раз выделяют mission critical часть и нет. В том числе ради того, чтобы иметь возможность обновлять продукт и поставлять новые фичи достаточно часто, когда это не касается mission critical. И, наоборот, иметь стабильность и обновлять только через долгие процедуры и сертификации то, что является mission critical.
                                                                                                  Сообщение отредактировано: D_KEY -
                                                                                                    Цитата D_KEY @
                                                                                                    Это вполне может соблюдаться на практике. А цель agile трансформации в том, чтобы в компании именно так все и было устроено.

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

                                                                                                    Цитата D_KEY @
                                                                                                    Так следование этим принципам как раз и позволяет надежно и стабильно быстро поставку осуществлять.

                                                                                                    Нет. Качество противоположно скорости. Всегда.

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

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

                                                                                                    Добавлено
                                                                                                    Цитата D_KEY @
                                                                                                    когда это не касается (mission critical)

                                                                                                    Ну так я об этом и говорил.
                                                                                                      Цитата korvin @
                                                                                                      Ну тебе точно стоит прогуляться по многим компаниям и объяснить им это. =)

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

                                                                                                      Добавлено
                                                                                                      Цитата korvin @
                                                                                                      Нет. Качество противоположно скорости. Всегда.

                                                                                                      Нет. Если за это мы готовы платить больше денег ;)
                                                                                                      Например, мой опыт говориь, что CI/CD улучшает и качество и скорость. Но требует наличие специалистов и постоянный ресурс на поддержку.

                                                                                                      Добавлено
                                                                                                      Цитата korvin @
                                                                                                      Ага, надо доносить, обычно до них это всё равно не доходит

                                                                                                      Ну вот я и говорю, что проблема в коммуникации.
                                                                                                      Ни одному PO не понравится, когда команда внезапно встанет и не сможет фичи делать из-за завала техдолга. Ни одному PO не понравится, если при реализации новых фич, вы будете отламывать старые. И т.д. и т.п.

                                                                                                      Добавлено
                                                                                                      Цитата korvin @
                                                                                                      Заодно, рассказать, какие это даёт преимущества в условиях рыночной конкуренции

                                                                                                      Тут есть нюанс. Если у бизнеса все ок, то он не станет меняться ;)

                                                                                                      Добавлено
                                                                                                      Wound, ты видимо хочешь хороший обстоятельный ответ. Сейчас у меня на него нет времени. Возможно, если позже оно у меня появится, я постараюсь ответить. Но на самом деле ты можешь погуглить по ключевым словам, которые я привел. Материалов много, вряд ли я тут скажу что-то отличное. При этом научить этим подходам на форуме нельзя. Но ты можешь поискать, может быть есть вебинары/курсы какие-то выложенные.
                                                                                                        Цитата D_KEY @
                                                                                                        Если за это мы готовы платить больше денег

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

                                                                                                        Цитата D_KEY @
                                                                                                        Например, мой опыт говориь, что CI/CD улучшает и качество и скорость.

                                                                                                        Мой опыт говорит, что компании под CI/CD понимают настройки серверов сборки и деплоя, а не методологию.

                                                                                                        Цитата D_KEY @
                                                                                                        Ну вот я и говорю, что проблема в коммуникации.

                                                                                                        Это не коммуникация, а приоритеты и условия. Не важно, смог ли ты донести мысль, что рефакторинг важен, если конкурент выкатил продукт быстрее, даже наговнокодив его без всяких скрамов и CI/CD, просто абы как — он успел занять рынок быстрее.

                                                                                                        Цитата D_KEY @
                                                                                                        Если у бизнеса все ок, то он не станет меняться

                                                                                                        Если у бизнеса всё ОК, то он и так не станет особо рашить за фичами, пытаясь выиграть в конкурентной гонке за рынок, и можно на расслабоне фиксить минорные баги, оптимизировать производительность и рефакторить код для лучшего maintainability.

                                                                                                        Добавлено
                                                                                                        А причина популярности всей этой около-agile-херни просто в том, что бизнесу так проще оценить работу программеров, их вклад и т.п., вот и всё, т.е. свести программирование к простому ремеслу, а ля работы у станка или типа того.
                                                                                                          Цитата D_KEY @
                                                                                                          Wound, ты видимо хочешь хороший обстоятельный ответ. Сейчас у меня на него нет времени. Возможно, если позже оно у меня появится, я постараюсь ответить. Но на самом деле ты можешь погуглить по ключевым словам, которые я привел. Материалов много, вряд ли я тут скажу что-то отличное. При этом научить этим подходам на форуме нельзя. Но ты можешь поискать, может быть есть вебинары/курсы какие-то выложенные.

                                                                                                          Да, я хотел бы получить хороший обстоятельный ответ. Если нет времени, хорошо, я могу подождать, как тебе будет удобно - прям бери расписывай. Мне реально интересно, вдруг есть такие подходы, о которых я не знаю? Я гуглил все термины, которые ты писал в ходе нашей дискуссии, даже термин "impact mapping" загуглил. НО по coding by design - актуальной и вменяемой информации я не нашел. Я допускаю что не так и не там ищу. По этому было бы просто супер, если бы ты привел какую то вменяему инфу об этом, видео/статьи/еще что то. Ну реально из того ролика что ты постил, я не понял идеи. Если рассказами, то лучше тексом, там проще перечитывать, если картинками - то можно и видео конечно.
                                                                                                          Я не прошу учить меня чему то, просто прошу прояснить общие принципы данных подходов. Я пока не увидел как то, что ты привел может заменить блок-схемы. Ну зрительная инфа лучше восприниматся для понимания того, что надо сделать как по мне, чем кодом. Так же как по мне(конечно это субъективно) - на пальцах(блок-схемы) - лучше отражают то, что делает та или инная система.
                                                                                                          Т.е. в принципе все эти UML диаграммы нужны для того, что бы понимать как что с чем взаимосвязано, как оно работает, т.е. смотря на диаграмму, ты понимаешь задумку автора. Тебе код - на этом этапе, накуй не уперся, тебя интересует - как оно все вместе взаимодействует. Вот диаграммы в данном случае по моему глубокому убеждению, доносят данные знания очень быстро и очень эффективно.

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

                                                                                                          А как другие подходы дадут больший профит? Я пока не понимаю, ты не объяснил. Курить интерфейсы того же OTPLogonProvider на майкрософте и примеры одного и того же кода? Нет уж, извините. Ты сам попробуй сыграть в угадайку по коду, которого у тебя нет. Напиши банально схему изменения пароля/просроченного пароля, владея всеми исходниками какие только найдешь в гугле(а их к слову много) на майкрософтовский Login Provider. Просто имел я опыт с этим, тонну кода перечитал, кучу времени потратил, но нет же вменяемых блоксхем, приходится код курить.

                                                                                                          Вот у меня такое мнение. Так что как будет время, обязательно дай обстоятельно хороший ответ. Мне он правда интересен, возможно что то новое расскажешь, я что то новое для себя узнаю.
                                                                                                          Сообщение отредактировано: Wound -
                                                                                                            Цитата korvin @
                                                                                                            т.е. свести программирование к простому ремеслу, а ля работы у станка или типа того.

                                                                                                            Да, странный у тебя agile.

                                                                                                            Добавлено
                                                                                                            Цитата Wound @
                                                                                                            Ну зрительная инфа лучше восприниматся для понимания того, что надо сделать как по мне, чем кодом. Так же как по мне(конечно это субъективно) - на пальцах(блок-схемы) - лучше отражают то, что делает та или инная система.

                                                                                                            Возможно, я как-то криво высказывал свои мысли. Я полностью согласен с тем, что ты тут пишешь :)

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

                                                                                                            Спор-то был не об этом, а о том, чтоб проектировать UMLем всю систему, а потом кодить.
                                                                                                            Вот я считаю такой подход неэффективным.
                                                                                                              Цитата D_KEY @
                                                                                                              Да, странный у тебя agile.

                                                                                                              Это не у меня =)
                                                                                                                Цитата D_KEY @
                                                                                                                Спор-то был не об этом, а о том, чтоб проектировать UMLем всю систему, а потом кодить.
                                                                                                                Вот я считаю такой подход неэффективным.

                                                                                                                Нет, ты прикалываешься? При такой постановке вопроса - я как бы с тобой согласен. Конечно - это маразм проектрировать UMLem всю систему а потом кодить. Это и правда 90-80 года, как ты раньше писал. Я лично вел речь об использовании блок-схем в принципе.
                                                                                                                Но с тобой я спорить начал после того, как ты сказал что чем больше схем, тем хуже спроектирована программа. Я в данном случае в корне не согласен! Да это конечно вполне может быть . Но это не основной критерий того, что программа плохо спроектирована. Еще бывает так, что программа сразу охватывает много разных концепций и устройств, т.е. так сложилось что очень много зависимостей в самой системе заложено технологически от нее не зависяще.
                                                                                                                Допустим тебе нужно работать с каким то девайсом, а еще иметь веб интерфейс для работы с ним. Уже несколько зависимостей появляется, даже без кода. Вот об этом я. И блок-схемы в данном случае - очень сильно выручают, особенно когда еще и система спроектирована криво.
                                                                                                                Сообщение отредактировано: Wound -
                                                                                                                  Цитата Wound @
                                                                                                                  Конечно - это маразм проектрировать UMLem всю систему а потом кодить. Это и правда 90-80 года, как ты раньше писал.

                                                                                                                  Ну хоть тут мы согласны :)

                                                                                                                  Цитата
                                                                                                                  Но с тобой я спорить начал после того, как ты сказал что чем больше схем, тем хуже спроектирована программа.

                                                                                                                  Я сказал вот так:
                                                                                                                  Цитата D_KEY @
                                                                                                                  На правах вброса: чем хуже система спроектирована, тем больше необходимы диаграммы :)


                                                                                                                  Это несколько отличается от того, что ты сейчас написал ;)
                                                                                                                  0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                                                                                                  0 пользователей:


                                                                                                                  Рейтинг@Mail.ru
                                                                                                                  [ Script execution time: 0,1472 ]   [ 17 queries used ]   [ Generated: 27.01.23, 01:26 GMT ]