О чем этот материал
Практические советы по учебе, собеседованиям, привычкам и росту в IT.
Это адаптированная версия учебной презентации: слайды разобраны в формате обычной статьи, чтобы материал было легче читать с телефона и возвращаться к нужным блокам позже.
Что внутри
Ниже краткий план материала. По нему удобно понять, в каком порядке разбирать тему.
- Поговорим о некоторых способах сделать код более понятным
- Поговорим о том что такое самодокументируемый код
- DRY и переиспользование кода
- Анонимные функции (+ замыкания)
- Работа с ошибками в Go (+ panic)
- Почему else не нужны и как делать код проще
- Еще что-нибудь…
- Разберем вопросы
Самодокументируемый код
Мы сейчас не про генерацию документации из кода или аннотаций
Не используем магические слова и цифры
Я сказал не используем…
DRY и переиспользование кода
DRY - Don’t Repeat Yourself
Анонимные функции
Для простых, одноразовых операций: Если функция используется только один раз и её логика проста, анонимная функция может быть более читаемой и лаконичной.
Для инкапсуляции логики: Анонимные функции позволяют инкапсулировать логику прямо на месте использования, что может улучшить (а может и нет) читаемость кода.
Для работы с функциями высшего порядка: Анонимные функции часто используются в качестве аргументов для функций высшего порядка, таких как map, filter и reduce. Обычно если надо передать
кастомную функцию в качестве аргумента
Замыкания
Работа с ошибками
Работа с ошибками. Нет стектрейса, но есть errors.Wrap()
"github.com/pkg/errors"
Panic
В Go обычно рекомендуется избегать использования panic и вместо этого возвращать ошибки, которые можно обработать. Однако есть ситуации, в которых использование panic может быть
оправданным:
Инициализация: Если ваш код не может корректно инициализироваться (например, не удается загрузить необходимый конфигурационный файл или установить
соединение с базой данных), использование panic может быть оправданным.
Panic. Но лучше не надо
Ожидаемые ошибки: Если ошибка является ожидаемой частью поведения программы
(например, ошибка ввода-вывода, неверный пользовательский ввод и т.д.), следует возвращать ошибку, а не вызывать panic.
В библиотеках: Если вы пишете библиотеку, которую будут использовать другие программы, избегайте panic. Вместо этого возвращайте ошибки, которые пользователи вашей библиотеки
могут обработать.
else не нужны
Ранний выход
Иногда можно инвертировать условие if() и код станет проще
Слайсы и массивы
Чистая архитектура
KISS - Keep It Smart & Simple
DRY - Don’t Repeat Yourself
SOLID (больше про ООП, но вообще везде хорошо)