На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (4) « Первая ... 2 3 [4]  все  ( Перейти к последнему сообщению )  
> UML vs Нафиг
   
пользуете ли вы это в своей деятельности?
Гости не могут просматривать результаты голосования.
Гости не могут голосовать 
    Цитата 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,0583 ]   [ 17 queries used ]   [ Generated: 4.02.23, 22:29 GMT ]