Ваши процессы попахивают. Как это понять и что делать? / Филипп Дельгядо

Поделиться
HTML-код
  • Опубликовано: 29 дек 2024

Комментарии • 15

  • @asbestoable
    @asbestoable 7 месяцев назад +2

    "конструктивная таксичность" )) новый для меня термин, по сути выдуманный токсичными людьми дабы отделить их токсичность как нечто приемлемое, потому как "они не такие" )))

  • @kirillsulim
    @kirillsulim 2 года назад

    Ошибка в фамилии либо на слайде либо в описании ролика

  • @Olga-pc3bm
    @Olga-pc3bm Год назад +2

    Ну такое... делайте хорошо, плохо не делайте. Думайте головой. Подумали? А зачем вы это напридумали? так Делать не надо. А как надо? я же говорил - надо делать хорошо и думать головой.

  • @nihromikusmetallum3051
    @nihromikusmetallum3051 10 месяцев назад

    Книга из доклада - Месяц под звездами фантазии Б.Л Злотин А.В Зусман

  • @olegprog
    @olegprog Год назад

    есть интересные мысли, но отказаться от код-ревью как-то всё равно страшновато

  • @ИльяСултанов-у6з

    Сначала мы пишем процессы для сотрудников, потом насаждаем соблюдение этих процессов в командах, и в конце выясняем, что формальное отношение к работе, то есть соблюдение процессов - это плохо.
    Товарищ, ну нельзя же так:)))

  • @juliettejolly6646
    @juliettejolly6646 Год назад

    Круть!

  • @annntoha
    @annntoha Год назад

    Люблю Фила...

  • @westrio2
    @westrio2 3 года назад +11

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

    • @phillipdelgyado9790
      @phillipdelgyado9790 3 года назад +2

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

    • @GP-ez5ms
      @GP-ez5ms 2 года назад +4

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

    • @phillipdelgyado9790
      @phillipdelgyado9790 2 года назад +3

      @@GP-ez5ms Увы, code review - не самый удачный способ для всех этих задач. Лучше смотреть на другие варианты peer review, у меня про это есть отдельный доклад: ruclips.net/video/EaLtDnTgBis/видео.html

    • @oeaoo
      @oeaoo Год назад

      В данном случае важно как, а не что.

    • @Olga-pc3bm
      @Olga-pc3bm Год назад

      Не парься, этот человек не пишет код сам каждый день, его задача умничать, рисуя диаграммы а ля "архитектор" и кидать понты на подобных сходках в мос-ИТ тусовке. Он конечно же сочиняет, что мол пишет, но по уровню дискуссии видно, что он ни в зуб ногой в проблемах программирования, написания кода хороших практик. Просто следить за новинками языка, наверное. Узнав поближе понимаешь, что бывший DBA так и не ушёл от процедурного мышления. Поэтому ему норм когда REST это вызов конкретных методов вместо ресурса и когда кодревью - это плохо. Одним словом информационный цыганин умело вливающий в мозг работодателям.

  • @pppdddqqqbbb
    @pppdddqqqbbb Год назад

    Гениальный доклад, само-описывающий - вроде бы и не инфоцыганство, но немножко им попахивает… ;)