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