Как для меня выглядит хороший backend-код

Приятно, когда код красиво выглядит. Чистые классы, понятно названные методы, аккуратная структура пакетов — всё это важно.

Но чем больше реальных систем я собираю, тем яснее, что хороший backend-код состоит не только из этого.

Код, который вы прочитаете завтра

Хороший код для меня — тот, который быстро объясняет, что он делает: завтра, когда я открою его снова, или когда его откроет другой разработчик.

• Имя метода должно говорить, что он делает.
• Бизнес-правило не должно быть спрятано.
• Должно быть понятно, зачем выполняется операция с базой.
• Исключение должно говорить больше, чем «что-то пошло не так».

И главное — код не должен скрывать поведение системы.

Не всему нужна абстракция

Чем дольше работаешь с Java, тем проще создавать абстракции.

• Создаёшь интерфейс.
• Создаёшь реализацию.
• Добавляешь фабрику.
• Добавляешь стратегию.

А потом ради простой операции приходится ходить по пяти классам.

Если абстракция выросла не из реальной потребности что-то менять, она порой просто делает код тяжелее для чтения.

Сейчас я отношусь к абстракциям осторожнее. Сначала проблема, потом паттерн. Не наоборот.

Clean code для меня — про другое

Clean code для меня — не короткие методы и не меньшее число строк. Clean code — это код, который не прячет бизнес-правило.

Например, если разработчик понимает по коду, почему бронь не удалось создать, для меня это хороший дизайн.

А если, чтобы выяснить причину неудачной операции, нужно пройти пять разных слоёв, я вижу здесь проблему — даже когда код технически выглядит «чистым».

Код пишут для изменений

Один из самых полезных уроков такой: код пишут не только для того, чтобы он работал сегодня.

• Завтра придёт новое требование.
• Добавится новое поле.
• Изменится бизнес-правило.
• Подключится другой сервис.
• Тот же код откроет другой разработчик.

Поэтому главное свойство хорошего backend-кода для меня — он не боится изменений. Выглядеть аккуратно хорошо. Но важнее, чтобы завтра его можно было изменить.