Можно и на голом css. Но tailwind предоставляет норм компоненты и ютилити классы. Это скорее как фреймворк для стилизации. Все им пользуются и не надо разрабатывать свой уникальный который не будет работать больше ни в какой компании. Есть свои плюсы.
Можно и свмому написать. Современный css крут. Но зачем?
В приеципе почти то же что говррил Кент Бек в XXX.
Я сам фанат чистого кода и архитектуры. Но тут он прав - обычно коммерчески успешный проект страдает от говнокода.
Но это не значит что он останется успешным. Есть много примеров где качество кода убивало проекты из-за скорости поставки.
Тот же гугл мог использовать деньги по другому - не погупать ютуб, а допилить свой сервис. Скачать все видео с ютуба и перезалить себе. Просто на тот момент было выгоднее купить ютуб.
Все правильно. Реакт с самого начала начал привлекать плохие решения. Я его забросил как только посмотрел на Редакс в бою. И еще раз подтвердил свои сомнения когда посмотрел на рутер.
Мне вообще не нравится что фреймворки пытаются переизобрести апи браузера.
Так же как не нравятся разработчики, которые не могут это апи использовать или не хотят в css.
Надо поделить фронт на отдельные микрофронты, если еще не поделено. И пкрепиливать страницу за страницей, удаляя крмпоненты - 100% они вызывают головную боль. Для отального есть tailwind.
Гипотеза проста - хороший код ускоряет разработку. Меньше кода - быстрее поставка.
Так что я могу попросить разрабов сообщать на ретро или тех синке о подобных проблемах. И попрошу чтобы они сразу исправляли это, а не создавали доп тикеты.
Придумаю какой-нибкдь бонус небольшой за исправление минимум 1 такого места.
И добавлю сонар- буду смотреть на общий maintainability index для начала. А когда интегрирую DORA - посмотрю корреляцию.
Я получил код в плачевном состоянии, тут про метрики и бест практисы и говорить нечего. Скорее сборник примеров как делать не надо. По этому мне еще предстоит интегрировать все эти инструменты и метрики, выстраивать культуру и пайплайны.
Рад что у вас получилось. Хорошо если оно так работает.
Говорят, что доска отражает накопление знания и нельзя двигать тикеты назад. У вас же на доске отдельная колонка для тестирования. Как вы будете проводить доработку, если найден дефект? Перенесите обратно в разработку?
Если не разбивать о них лоб - это как раз про то, что они потеряли смысл.
Идеи не меняются. Их бывает толкуют не верно. Но скорее появится что-то новое, чем старое изменит смысл.
Скрам - не скрам, если его изменить. Но люди в скудоумии своём не могут в абстракции и дать другой идее новое имя. По этому как те зомби повторяют - Мозги.
Спасибо за статью. Подскажите пожалуйста, как адекватно измерять queue time? Метрики берутся со слов участников примерно. Или там нужен супер формальный подход к использованию трекера?
Какие метрики лучше измерять чтобы видеть разницу в 2х командах адекватно?
Попробуйте еще спросить бездушную машину: "Откуда появилась должность DevOps инжинер? Соответствует ли название должностной инструкции? Соответствует ли эта роль в принципе определению DevOps?"
За меня это все описали другие люди. Хоть тот же DevOps Topologies почитайте или Dave Farley с Кентом Беком или Р Мартина. Изучите что они говорят про ответственность разработчиков и процессы.
И если вам автор говорит что DevOps это культура - то это культура. Не надо переопределять термин. Администратор не может в культуру. Психолог и соц инжинер может.
Культуру вот пытались инженерить в некоторых странах. Делается это через PsyOps, СМИ, книги, систему обучения, кино.
Писать пайплайны и IaC любой может. Главное чтобы мотивация была.
Вот автор статьи приводит дора метрики. Все эти метрики будут нулевым, если разработчики не пишут код, не добавляют тесты, не пишут миграции, не умеют пользоваться версионированием апи. И какая бы там крутая автоматизация не была - все без толку.
К тому же все эти метрики существуют только на уровне команды. Отдельный человек их не делает. По тому что базовая единица поставки софта - команда.
С другой стороны если разраб делает это все - получается он девопс. Даже заменив библиотеку тестирования или миграции бд - ему придётся поправить пайплайн. Т.е. он уже вовлечен в автоматизацию. Выходит все разработчики - девопсы?
Там столько логических ошибок с этими дЕво-Псами, что если начну все расписывать, то придётся бросить работу и только и строчить статьи да ответы.
Культуру может вырастить только лидер поощряя определённое поведение, делая каждого в команде ответственным за результат. Когда разраб несёт ответственность за свою работу - он сам все автоматизирует и улучшает метрики. Ему не нужен костыль в виде пайплайнописца. Внешняя экспертиза про инфру пригодится. Счета за инфру пригодятся. Разрабы сами хотят все оптимизировать.
Забирать доступы - это не девопс. Это ото про безопастность. Возможно это и было нужно, но там много вопросов к исполнению и что дали в замен.
Я считаю это бесполезно, т.к. люди работающие с данными все равно их получат. Не из базы, так из какого-нибудь пресловутого даталейка.
Обычно это делают опсы которые считают что все вокруг овечки и не несут персональной ответственности перед работодателем. Хотя по факту, это как отобрать у дворника метлу.
Были у меня с такими ребятами долгие разговоры. Потом приходили юристы и объясняли что они не правы.
Идея, тем не менее, в сути своей не изменилась. Поправили чутка вординг, чтобы улучшить понимание.
Менять описание для понятности это не тоже что менять суть.
Можно просто прикрутить вкусную систему монетизации или дать премиум фичи бесплатно. Народ от рекламы убежал бы только пятки сверкали бы.
Короче варианты были. Но что сделали - то сделали.
Можно и на голом css. Но tailwind предоставляет норм компоненты и ютилити классы. Это скорее как фреймворк для стилизации. Все им пользуются и не надо разрабатывать свой уникальный который не будет работать больше ни в какой компании. Есть свои плюсы.
Можно и свмому написать. Современный css крут. Но зачем?
В приеципе почти то же что говррил Кент Бек в XXX.
Я сам фанат чистого кода и архитектуры. Но тут он прав - обычно коммерчески успешный проект страдает от говнокода.
Но это не значит что он останется успешным. Есть много примеров где качество кода убивало проекты из-за скорости поставки.
Тот же гугл мог использовать деньги по другому - не погупать ютуб, а допилить свой сервис. Скачать все видео с ютуба и перезалить себе. Просто на тот момент было выгоднее купить ютуб.
Все правильно. Реакт с самого начала начал привлекать плохие решения. Я его забросил как только посмотрел на Редакс в бою. И еще раз подтвердил свои сомнения когда посмотрел на рутер.
Мне вообще не нравится что фреймворки пытаются переизобрести апи браузера.
Так же как не нравятся разработчики, которые не могут это апи использовать или не хотят в css.
Надо поделить фронт на отдельные микрофронты, если еще не поделено. И пкрепиливать страницу за страницей, удаляя крмпоненты - 100% они вызывают головную боль. Для отального есть tailwind.
Я выбираю htmx + alpine по дефолту. Если понадобится фреймворк - скорее всего возьму svelte.
Так какого рода изменения были сделаны авторами?
Насколько мне известно там были уточнения для тех кто может вольно интерпретировать фреймворк.
Но никто не убирал какие-то митинги или менял их цель.
Как говорил Фаулер: "if you can't change your team - change your team" :)
Правильно сделали. Нечего в чужом болоте тонуть.
Не вопрос. Пингану потом.
Гипотеза проста - хороший код ускоряет разработку. Меньше кода - быстрее поставка.
Так что я могу попросить разрабов сообщать на ретро или тех синке о подобных проблемах. И попрошу чтобы они сразу исправляли это, а не создавали доп тикеты.
Придумаю какой-нибкдь бонус небольшой за исправление минимум 1 такого места.
И добавлю сонар- буду смотреть на общий maintainability index для начала. А когда интегрирую DORA - посмотрю корреляцию.
Я получил код в плачевном состоянии, тут про метрики и бест практисы и говорить нечего. Скорее сборник примеров как делать не надо. По этому мне еще предстоит интегрировать все эти инструменты и метрики, выстраивать культуру и пайплайны.
Писать простой код могут не только лишь все.
Сочувствую. Но эта проблема в образе мышления. Кому-то изначально платили за строки кода. А потом он пришёл в продукт, а привычка осталась.
Сам сейчас таких переучиваю. Начну с выставления правильных kpi
Имею ввиду что метрики очень контекстно зависимы. Как понять почему команда А перформит лучше команды Б? На какие метрики и как надо смотреть?
Рад что у вас получилось. Хорошо если оно так работает.
Говорят, что доска отражает накопление знания и нельзя двигать тикеты назад. У вас же на доске отдельная колонка для тестирования. Как вы будете проводить доработку, если найден дефект? Перенесите обратно в разработку?
А null? Там же были проверки на нул в каждом методе? :)
У меня ровно такая же проблема с командой. Только теперь я могу на это повлиять.
Если не разбивать о них лоб - это как раз про то, что они потеряли смысл.
Идеи не меняются. Их бывает толкуют не верно. Но скорее появится что-то новое, чем старое изменит смысл.
Скрам - не скрам, если его изменить. Но люди в скудоумии своём не могут в абстракции и дать другой идее новое имя. По этому как те зомби повторяют - Мозги.
Спасибо за статью. Подскажите пожалуйста, как адекватно измерять queue time? Метрики берутся со слов участников примерно. Или там нужен супер формальный подход к использованию трекера?
Какие метрики лучше измерять чтобы видеть разницу в 2х командах адекватно?
Вводим новый грейд - попугай.
Попробуйте еще спросить бездушную машину: "Откуда появилась должность DevOps инжинер? Соответствует ли название должностной инструкции? Соответствует ли эта роль в принципе определению DevOps?"
Она вам без эмоций сама все и расскажет.
Ответ в духе "а чего добился ты?"
За меня это все описали другие люди. Хоть тот же DevOps Topologies почитайте или Dave Farley с Кентом Беком или Р Мартина. Изучите что они говорят про ответственность разработчиков и процессы.
И если вам автор говорит что DevOps это культура - то это культура. Не надо переопределять термин. Администратор не может в культуру. Психолог и соц инжинер может.
Культуру вот пытались инженерить в некоторых странах. Делается это через PsyOps, СМИ, книги, систему обучения, кино.
Писать пайплайны и IaC любой может. Главное чтобы мотивация была.
В том то и дело, что это так не работает.
Вот автор статьи приводит дора метрики. Все эти метрики будут нулевым, если разработчики не пишут код, не добавляют тесты, не пишут миграции, не умеют пользоваться версионированием апи. И какая бы там крутая автоматизация не была - все без толку.
К тому же все эти метрики существуют только на уровне команды. Отдельный человек их не делает. По тому что базовая единица поставки софта - команда.
С другой стороны если разраб делает это все - получается он девопс. Даже заменив библиотеку тестирования или миграции бд - ему придётся поправить пайплайн. Т.е. он уже вовлечен в автоматизацию. Выходит все разработчики - девопсы?
Там столько логических ошибок с этими дЕво-Псами, что если начну все расписывать, то придётся бросить работу и только и строчить статьи да ответы.
Культуру может вырастить только лидер поощряя определённое поведение, делая каждого в команде ответственным за результат. Когда разраб несёт ответственность за свою работу - он сам все автоматизирует и улучшает метрики. Ему не нужен костыль в виде пайплайнописца. Внешняя экспертиза про инфру пригодится. Счета за инфру пригодятся. Разрабы сами хотят все оптимизировать.
Забирать доступы - это не девопс. Это ото про безопастность. Возможно это и было нужно, но там много вопросов к исполнению и что дали в замен.
Я считаю это бесполезно, т.к. люди работающие с данными все равно их получат. Не из базы, так из какого-нибудь пресловутого даталейка.
Обычно это делают опсы которые считают что все вокруг овечки и не несут персональной ответственности перед работодателем. Хотя по факту, это как отобрать у дворника метлу.
Были у меня с такими ребятами долгие разговоры. Потом приходили юристы и объясняли что они не правы.