Количество или качество 🤔
Несмотря на наш технический и иногда творческий род деятельности (именно творческий при решении нестандартных кейсов), менеджеры, любого звена, прежде всего оценивают разработчиков через количественные характеристики - задачи, сторипоинты, часы разработки, а бывает и коммиты. По этой причине часть из нас бывает пренебрегает качеством решения задач, пытаясь успеть выполнить то ли 'хотелки' бизнеса, то ли доказать себе свою продуктивность. На самом деле это очень опасная ловушка, в которую попадают многие - так уж сложилось, что последнее время мне все больше приходится наблюдать чужой код (что я считаю хоть и допнагрузкой, но все же плюсом).
Попытка успеть многое в ущерб качеству решения задачи приводит к большему количеству дефектов, иногда даже очень и это только то, что находится на поверхности при тестировании фичей и обнаруживается на раннем этапе. Бомбы замедленного действия могут сработать в самый неподходящий момент, и решение последствий привести к громадным затратам ресурсов (на такое даже есть статистика в умных книжках).
Конечно ошибки не исключены даже при должном подходе к разработке, но вы должны понять одно - нельзя всегда идти на поводу управленцев, иногда могут приниматься не очень хорошие решения, мною в том числе, но это в основном временные и самое главное обдуманные по рискам как со стороны бизнеса, так и разработки. Оправдание из разряда 'нас торопят' не должно быть постоянным оправданием костылей.
Несмотря на наш технический и иногда творческий род деятельности (именно творческий при решении нестандартных кейсов), менеджеры, любого звена, прежде всего оценивают разработчиков через количественные характеристики - задачи, сторипоинты, часы разработки, а бывает и коммиты. По этой причине часть из нас бывает пренебрегает качеством решения задач, пытаясь успеть выполнить то ли 'хотелки' бизнеса, то ли доказать себе свою продуктивность. На самом деле это очень опасная ловушка, в которую попадают многие - так уж сложилось, что последнее время мне все больше приходится наблюдать чужой код (что я считаю хоть и допнагрузкой, но все же плюсом).
Попытка успеть многое в ущерб качеству решения задачи приводит к большему количеству дефектов, иногда даже очень и это только то, что находится на поверхности при тестировании фичей и обнаруживается на раннем этапе. Бомбы замедленного действия могут сработать в самый неподходящий момент, и решение последствий привести к громадным затратам ресурсов (на такое даже есть статистика в умных книжках).
Конечно ошибки не исключены даже при должном подходе к разработке, но вы должны понять одно - нельзя всегда идти на поводу управленцев, иногда могут приниматься не очень хорошие решения, мною в том числе, но это в основном временные и самое главное обдуманные по рискам как со стороны бизнеса, так и разработки. Оправдание из разряда 'нас торопят' не должно быть постоянным оправданием костылей.
👍3
JVM Brain | Java&Kotlin
Для удобства навигации по чату были созданы теги, в информации о группе они не очень удобны, поэтому оставлю тут и кину в закреп #задачавыходногодня - небольшие тесты #mustread - что почитать (из лично прочитанного) #вакансия - тут можно найти работу (обычно…
Аларм! В закрепе есть полезные материалы. Как напоминание тем, кто вдруг забыл или не знал.
👍2
Опрос анонимный. На скольких работах вы сейчас в айти?
Anonymous Poll
63%
Единственная
8%
Две
0%
Три
29%
Не работаю в айти
Знаете, что может быть хуже апдейта зависимостей своего проекта?
Правильно - апдейт зависимостей чужого проекта, особенно, если это либа, которая транзитивно тянет за собой ещё несколько нуждающихся в апдейтах либ, а исходники есть не на все.
Собственно примерно этим адом я занимаюсь последние 4 рабочих дня 😤
У меня даже появляется мысль а не переписать ли все с нуля, скорее всего этим и закончится, но я должен был попытаться.
В этом есть и плюсы- гредловые плагины я еще не писал, вот как раз и вариант прокачки нашёлся.
Правильно - апдейт зависимостей чужого проекта, особенно, если это либа, которая транзитивно тянет за собой ещё несколько нуждающихся в апдейтах либ, а исходники есть не на все.
Собственно примерно этим адом я занимаюсь последние 4 рабочих дня 😤
У меня даже появляется мысль а не переписать ли все с нуля, скорее всего этим и закончится, но я должен был попытаться.
В этом есть и плюсы- гредловые плагины я еще не писал, вот как раз и вариант прокачки нашёлся.
🤔1
JVM Brain | Java&Kotlin
Знаете, что может быть хуже апдейта зависимостей своего проекта? Правильно - апдейт зависимостей чужого проекта, особенно, если это либа, которая транзитивно тянет за собой ещё несколько нуждающихся в апдейтах либ, а исходники есть не на все. Собственно примерно…
На самом деле интересная история вышла. Поделюсь же этим 👇
Доработать плагин удалось, не без мучений 😬, но большая часть функционала осталась рабочей. Ох и наковырялся я в древних проектах.
Из опыта:
- не мешайте пакеты javax и jakarta, в рантайме при попытке инициализировать классы для работы с xml вы получите ошибку
- старайтесь брать библиотеки посвежее, не только в основном функционале, но и для тестов
- не забывайте править Jenkins файлы - сборка в любом случае идёт через них
- учитывайте, что под капотом может быть какая-то хитрая логика
- maven и gradle кэшируют зависимости, иногда даже при принудительном рефреше - приходилось для точности удалять папки.
Доработать плагин удалось, не без мучений 😬, но большая часть функционала осталась рабочей. Ох и наковырялся я в древних проектах.
Из опыта:
- не мешайте пакеты javax и jakarta, в рантайме при попытке инициализировать классы для работы с xml вы получите ошибку
- старайтесь брать библиотеки посвежее, не только в основном функционале, но и для тестов
- не забывайте править Jenkins файлы - сборка в любом случае идёт через них
- учитывайте, что под капотом может быть какая-то хитрая логика
- maven и gradle кэшируют зависимости, иногда даже при принудительном рефреше - приходилось для точности удалять папки.
👍1