Почему плохой код ощущается как плохой интерфейс (часть 2)
В прошлой части мы разобрали кошелёк Миллера: 👉 мозг не переваривает слишком много информации сразу
Теперь давайте посмотрим, что происходит в коде.
И вот здесь многие разработчики удивляются. Оказывается, тот же самый принцип работает в ООП.
Представьте функцию:
function processUser( name, age, email, address, phone, role, permissions, avatar, settings, notifications ) {}
Всё работает.
Но попробуйте быстро понять, что здесь происходит. Сложно? Что произошло?
Мы дали функции слишком много ответственности. Она должна «держать в голове» слишком много деталей. Это как если дать человеку одновременно: телефон
банковскую карту, паспорт, ключи, документы, список покупок.
Руки заняты. Что-то обязательно упадёт.
Вот тут и появляется ООП. Что оно делает? 👉 группирует связанные вещи
Например:
class User { constructor(profile, settings) { this.profile = profile this.settings = settings } }
Теперь у нас есть структура: User
├── Profile
│ ├── name
│ ├── age
│
└── Settings
├── theme
└── notifications
Что изменилось?
Мы не убрали данные.
👉 Мы сделали их понятными для восприятия
И это ровно то же самое, что делает UX-дизайнер. Мы просто спрятали сложность за логичными блоками. И, кстати, API — туда же.
Плохой вариант:
GET /users/getAllUsersWithOrdersPaymentsAndNotifications Вроде удобно.
Но он пытается вернуть всё сразу.
Хороший вариант: GET /users
GET /users/{id}/orders
GET /users/{id}/payments
Мы сделали простую вещь: 👉 разделили ответственность
Заметили? UX, ООП и API делают одно и то же:
👉 уменьшают нагрузку на мозг И теперь главный вопрос: если принцип везде один…
👉 что тогда отличает действительно сильного разработчика?
Разберём в финальной части.