Количество или качество 🤔

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

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

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

Встречайте - теперь это транслируется и на хх. Что думаете?

Есть такое?

Аларм! В закрепе есть полезные материалы. Как напоминание тем, кто вдруг забыл или не знал.

Вторую-то проблемно найти, а тут столько, понятное дело, что не одновременно

А я-то думал...

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

Собственно примерно этим адом я занимаюсь последние 4 рабочих дня 😤

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

В этом есть и плюсы- гредловые плагины я еще не писал, вот как раз и вариант прокачки нашёлся.

Весёлые истории экран покажет наш

https://youtube.com/shorts/OaQMGCF4RcQ?feature=share

Ты знаешь кому отправить

Знаком с Сашей пусть и заочно, но думаю будет интересно

На самом деле интересная история вышла. Поделюсь же этим 👇

Доработать плагин удалось, не без мучений 😬, но большая часть функционала осталась рабочей. Ох и наковырялся я в древних проектах.

Из опыта:
- не мешайте пакеты javax и jakarta, в рантайме при попытке инициализировать классы для работы с xml вы получите ошибку
- старайтесь брать библиотеки посвежее, не только в основном функционале, но и для тестов
- не забывайте править Jenkins файлы - сборка в любом случае идёт через них
- учитывайте, что под капотом может быть какая-то хитрая логика
- maven и gradle кэшируют зависимости, иногда даже при принудительном рефреше - приходилось для точности удалять папки.

Между тем первый миллион просмотров на одном видео 🎉, да и в целом пожалуй только за счёт него отметку прошёл

А вы как выбираете?

https://youtube.com/shorts/NnU_kxxObz8?feature=share