Всех с днём программиста! В этом посте я расскажу о сегодняшнем празднике.
День программиста - это профессиональный праздник, который отмечают в России по указу Медведева с 2009 года. В качестве даты для этого праздника был выбран 256-ой день года, это значит, что дата этого праздника плавающая в високосный год это 13 сентября, как например в это году (2023), а в следующем году - 12 сентября.
Число 256 для даты праздника было выбранное не просто так, вы уже возможно заметили что это 28. Это количество различных значений, которые можно выразить с помощью восьмиразрядного байта. Ну и ещё это самая большая степень двойки, которое помещается в году.
Сегодня 256-й день года, а это значит, что пришла пора поздравлять программистов с профессиональным праздником!
Поздравляем всех программистов Россельхозбанка и его дочерних компаний, а также коллег из других организаций. Желаем поменьше багов, побольше удачных идей, интересных проектов, доброго тимлида и отлаженных процессов!
Сегодняшняя дата выбрана не случайно! Это 256-й день в году. Сакральное число для IT-шников. Желаем всем дальнейшего развития и продвижения до 256-го уровня и выше. Как известно, совершенству нет предела. Поэтому дарим полезный подарок, который поможет прокачать ваши hard- и soft-skills — записи выступлений докладчиков конференции TestDriven Conf, которых ещё не было в открытом доступе.
Компания Microsoft выпустила версию 17.6.4 Visual Studio 2022 с исправлением ошибки утилизации ресурсов процессора при последовательном запуске нескольких тестовых проектов.
Ошибка была связана с постоянным опросом данных через testhost, в новой версии этот баг исправлен. Кроме того, в новой версии устранена проблема зависания IDE при сохранении файла C ++.
Подробнее обо всех исправлениях читайте на сайте разработчика.
Поучаствуйте плиз в опросе как вы проводите кодревью (если вы разработчик). Мне это нужно для презентации к митапу. Потом поделюсь статистикой, инсайтами и презентацией. Спасибо!
Недавно в очередной раз одернул своего джуна, когда он хотел написать такое
if (someVar != null) {
...
} else {
throw new NullpointerException()
}
Да, руками кидать NPE - это дичь. Но мне не нравится сам факт броска исключения посреди разухабистого бизнес процесса. От меня сразу же следует вопрос: это так и должно быть по спеке? Не должно. А значит - разработчик халтурит. Он или не разобрался в бизнес-процессе сам, или не напряг аналитика/лида/архитектора и не выяснил, что система должна делать в исключительной ситуации. throw здесь означает: "ой все, пусть оно как-нибудь само".
Лично мои правила по исключениям в Java/Kotlin:
Перед очередным throw ответь на 2 вопроса: а) кто адресат этого сообщения? б) что адресат должен сделать при получении? Нет ответов - не кидай исключение, а вместо этого лучше разберись в процессе.
Располагай весь кидающий исключения код компактно и предсказуемо. Например, пусть исключения кидают только валидаторы на входе хэндлеров, но не сервисы и не репозитории.
Пиши код как конечный автомат. Абсолютно любая дичь на входе должна быть ожидаема алгоритмом и должна приводить к чему-то на выходе, но не к истерике "ой, все".
Если чувствуешь в себе силы джедая, то изучи функциональный подход к обработке ошибок через алгебраические типы данных
Любое исключение в логах или в Sentry - повод не только исправить баг, но и поработать над собой
Рефакторинг — это изменение с сохранением поведения. Также, пишут что это именно небольшое изменение, а большое — это реинжиниринг. Я бы скорее акцентировал внимание, что это изменение в замкнутой области.
Основное отличие от переписывания — внесённые изменения не требуют менять смежные модули, которые не подвергались рефакторингу.
Примерно как ремонт квартиры — после ремонта окна и двери стоят на том же месте, несущие стены и коммуникации не затронуты, а внутри стало приятнее.
И тут же признаки того, что рефакторинг пошёл не по плану:
Забыли какой‑то ранее работающий функционал.
Полезли ошибки в других местах.
При правильном планировании и последовательном проведении рефакторинга допустить такие ошибки довольно сложно.
План работ определяет область для изменений и её границы, в результате получаем набор точек (методов), которые останутся неизменными. Это границы изменяемого кода.
Если внешние обращения изменяются, иногда бывает полезным новый код писать отдельно от старого, и главная фишка тут в том, что можно по готовности переключать пограничные точки со старого кода на новый. А перед удалением старого кода ещё раз проверить, что весь старый код отключили и ничего не упустили.
Таким образом, в каждый момент времени код сохраняет свою работоспособность и не теряет связанности.
Если вы хотя бы раз собирали набор Lego по приложенной схеме, вы помните основное правило: всё нужно делать строго последовательно и аккуратно. Допущенная ошибка где-то в середине конструкции может привести к тому, что вам придётся разбирать все последующие верхние уровни, чтобы её исправить.
Это же правило действует и при сборке мебели. Бывали ли у вас такие случаи, когда после сборки у вас оставалась какая-нибудь неиспользованная деталь? Вспомните, как сложно вернуться к тому шагу, где её нужно было использовать: придётся последовательно отменять все последующие шаги.
Программисты задумчиво дебажат старый код
Суть метода Lego заключается в том, чтобы всё сразу делать максимально внимательно и правильно: писать код, конструировать систему, сочинять текст, собирать тумбочку. Конечно, это не обезопасит вас от ошибок.
Применение этого метода может потребовать больше времени и усилий. Он не вписывается в проекты, где основная философия разработки — это склепать на коленке кое-как работающий код. Но сколько времени уйдёт на рефакторинг такого кода, например, через полгода?
На практике применение метода Lego означает, что вы не оставляете после себя черновиков, костылей, заплаток и подпорок. Если уж взялись писать процедуру, то на выходе выдаёте красивый, проверенный, полностью работающий код. И никаких «To do» и технического долга. Возможно, потом придётся переписать или дополнить процедуру, но с учётом текущей версии условий она написана идеально.
