Немного про практику. 💻 Технический дневник.📒

Впервые о нем я прочёл в книге 'Программист-прагматик'. Я и до этого делал некоторые заметки, но после стал намного чаще. О чем вообще эта идея - всякий раз, когда вы решаете какую-то задачу и сталкиваетесь с нестандартным кейсом, фиксируете это. Я последнее время использую телефон, несмотря на то, что бумага иногда даже лучший вариант. Просто блокнот в моменте не всегда под рукой.

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

В пользу поста выше. 👆

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

Как думаете заметят такой профиль в гитхабе?

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

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

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

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

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

Есть такое?

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

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

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

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

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

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

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

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

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

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

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