Почему плохой код ощущается как плохой интерфейс (часть 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

│ └── email

└── Settings

├── theme

└── notifications

Что изменилось?

Мы не убрали данные.

👉 Мы сделали их понятными для восприятия

И это ровно то же самое, что делает UX-дизайнер. Мы просто спрятали сложность за логичными блоками. И, кстати, API — туда же.

Плохой вариант:

GET /users/getAllUsersWithOrdersPaymentsAndNotifications Вроде удобно.

Но он пытается вернуть всё сразу.

Хороший вариант: GET /users

GET /users/{id}/orders

GET /users/{id}/payments

Мы сделали простую вещь: 👉 разделили ответственность

Заметили? UX, ООП и API делают одно и то же:

👉 уменьшают нагрузку на мозг И теперь главный вопрос: если принцип везде один…

👉 что тогда отличает действительно сильного разработчика?

Разберём в финальной части.

Почему плохой код ощущается как плохой интерфейс (часть 2) | Сетка — социальная сеть от hh.ru