Senior Software Vlogger

Документалочку про реакт посмотрели и обсудили. Терпеть смотрим про тайпскрипт! Как раз завтра пятница. За обедом посмотрю 🤓

https://youtu.be/U6s2pdxebSo?si=ewVwveu95C1SCAgj

Майкрософт опенсорснул 38 терабайт исследовательских данных связанных с AI

Утекла ссылка, которая должна была давать доступ к одному файлу, но она давала доступ к куда большему объему данных. В Ажур облаке есть особый вид ссылок с офлайн токеном. Этими ссылками очень удобно делиться, но которые можно неправильно сконфигурить. Помянем.

А вы говорите Яндекс.

https://www.wiz.io/blog/38-terabytes-of-private-data-accidentally-exposed-by-microsoft-ai-researchers

Вступай в семью 🫶 | YouTube | Twitter

Как правильно уйти в отпуск

Ваня написал пост про ужасную культуру отпусков на его месте работы (видимо так). Не надо работать из отпуска. Ниже пара хуков правильного отпуска.

Плавно переставай работать за неделю до отпуска
Чтобы правильно испариться с работы, нужно устроить градиент присутствия. Делегировать все свои дела другим людям. Выписать все задачи, которые надо подхватить и кто их подхватывает. Если ты работаешь до последней секунды, то у твоей команды будет стресс от внезапного расставания и они могут начать тебе звонить. Сообщать им свой номер или брать трубку — это ошибка новичка конечно.

Второй хук — плавное возвращение.
Ты уже вернулся, с тобой можно поговорить, но первый день ты тратишь на 999+ писем. Понятное дело, что ты их читаешь с конца. Если проблема уже разрешилась, то грохаешь всю цепочку. Второй день ты перенимаешь свои дела назад если ответственные не успели их закончить.

Третий хук — ответственный челик
Такой всегда есть в команде. Назначаешь с ним 1-1 на 3 день, он восстанавливает остаток контекста. Задаешь вопрос: какое дело требует моего внимания в первую очередь? И делаешь это одно дело.

Таким образом, за неделю вы полностью вернулис в работу не вызвав шока возврата чайка менеджера.

Учитесь правильно отдыхать.

https://t.me/dev_yttg/675

Как перестать делать баги?

Я работаю в айти где-то около 2 лет, замечаю за собой такой недостаток — очень много мелких багов при разработке, которые часто не выявляются при первичных тестах. В итоге приходится очень часто пушить хот-фиксы. Возможно это связано с самим проектом — стартап, надо быстро, ревью особого нет, серьезного тестирования тоже. Но и в целом я за собой замечал такой недостаток. Собственно вопрос — как этого избавиться? Понятно, есть обычные советы типа будь внимательней, тщательней тестируй свой код — я стараюсь, но все равно то тут, то там какая-то досадная ошибка вылезет постоянно.

Очень релевантный случай, потому что у меня случай один в один в команде.

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

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

С другой стороны стартап без ревью и тестирования — не самое лучше место для становления практик. Тем не менее, если нет ревью со стороны коллег, то можно делать ревью себе самому. Достаточно дать коду полежать пол дня, как он начинает забываться. Свежим взглядом можно поймать еще немного багов. Особенно если вести картотеку своих косяков. Поймал баг — записал в каком месте и почему он был пропущен. Потом, когда делаешь ревью — сверяешься со своими заметками, нет ли здесь похожего места.

С тестированием чуть сложнее. Если в проекте изначально не настроено окружение для тестирования, то писать и поддерживать тесты будет крайне сложно. Тут конечно кто-то, возможно даже ты, должен все один раз настроить, а потом поддерживать. Что в условиях стартапа и быстро растущей базы кода может быть довольно нетривиальной задачей. Тем не менее, добавить юнит тесты можно почти всегда довольно быстро, а они уже обеспечат хорошую страховку.

Руками тоже можно тестировать довольно успешно. Тут главное знать как. Тестировщики обычно не тестируют наобум. Тестировщики сначала пишут тест кейсы. Просто на естественном языке пишут, что они будут делать и что ожидают получить. Если система работает как описано в кейсе, то тест прошел. Эти тест кейсы можно тоже вытащить из того предварительного разбора задачи в псевдокод. Ну и тестировать конечно нужно не только успешный сценарий, но и все неуспешные ветки.

С опытом и разбор задачи, и тест кейсы получается держать в голове. Пока опыта набираешься — надо руками прописывать. Нос не вешай главное, все получится!

💁 Вопрос можно задать нажав на кнопку в закрепе.

https://seniorsoftwarevlogger.com/how-to-stop-making-bugs

Вступай в семью 🫶 | YouTube | Twitter