Ваши процессы попахивают. Как это понять и что делать? / Филипп Дельгядо
Вставка
- Опубліковано 25 лис 2024
- Приглашаем на конференцию TeamLead Conf++ 2024, которая пройдет 27 и 28 ноября в Москве!
Программа, подробности и билеты по ссылке: clck.ru/3DDSgX
---------
Единственная профессиональная конференция только для тимлидов
16 и 17 сентября 2021,
Санкт-Петербург, DESIGN DISTRICT DAA in SPB
Тезисы и презентация:
teamleadconf.r...
На конференции много рассказывают про выстраивание процессов разработки, формирование команды, о разнообразных полезных практиках и популярных методологиях. Но давайте поговорим, а когда пора менять ваши процессы, когда нужно начать применять полученные знания. Как понять, что имеющиеся процессы неудачны, что команда разваливается, что методология подобрана не та и практики уже не работают?
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
"конструктивная таксичность" )) новый для меня термин, по сути выдуманный токсичными людьми дабы отделить их токсичность как нечто приемлемое, потому как "они не такие" )))
Книга из доклада - Месяц под звездами фантазии Б.Л Злотин А.В Зусман
есть интересные мысли, но отказаться от код-ревью как-то всё равно страшновато
Сначала мы пишем процессы для сотрудников, потом насаждаем соблюдение этих процессов в командах, и в конце выясняем, что формальное отношение к работе, то есть соблюдение процессов - это плохо.
Товарищ, ну нельзя же так:)))
Ошибка в фамилии либо на слайде либо в описании ролика
Ну такое... делайте хорошо, плохо не делайте. Думайте головой. Подумали? А зачем вы это напридумали? так Делать не надо. А как надо? я же говорил - надо делать хорошо и думать головой.
Люблю Фила...
Круть!
Не согласен, что практики ревью кода через Pull Request по умолчанию попадает в разряд попахивающих. Наоборот, в большинстве ситуаций, ревью наиболее дешевый способ не пропускать пахнущий код.
Отсутствие код-ревью - это пахнущий процесс
Ну, это точно не "наиболее дешевый" способ, скорее уж "наиболее дорогой". Ровно поэтому практика и попахивающая всегда, ее используют не подумав про альтернативные пути решения возникающих проблем.
Мало того что это способ остановить поток дерьма от коллег, так это ещё и лёгкий способ шарить знания, практики и гарантировать из выполнение. Ещё это удобный способ выравнивать подходы с ньюкамерами.
@@GP-ez5ms Увы, code review - не самый удачный способ для всех этих задач. Лучше смотреть на другие варианты peer review, у меня про это есть отдельный доклад: ua-cam.com/video/EaLtDnTgBis/v-deo.html
В данном случае важно как, а не что.
Не парься, этот человек не пишет код сам каждый день, его задача умничать, рисуя диаграммы а ля "архитектор" и кидать понты на подобных сходках в мос-ИТ тусовке. Он конечно же сочиняет, что мол пишет, но по уровню дискуссии видно, что он ни в зуб ногой в проблемах программирования, написания кода хороших практик. Просто следить за новинками языка, наверное. Узнав поближе понимаешь, что бывший DBA так и не ушёл от процедурного мышления. Поэтому ему норм когда REST это вызов конкретных методов вместо ресурса и когда кодревью - это плохо. Одним словом информационный цыганин умело вливающий в мозг работодателям.
Гениальный доклад, само-описывающий - вроде бы и не инфоцыганство, но немножко им попахивает… ;)