Спочатку усе просто — маленький компонент, зрозумілий, логічний, швидкий. Але з часом, непомітно, маленькими кроками, він починає перетворюватись на монстра Франкенштейна: спочатку це прапорці isMobile чи isAdmin, згодом цілі шматки розмітки чи логіки та десяток колбеків на всі випадки життя. І ось в результаті перед вами дещо, в хитросплетіннях умовних конструкцій якого уже ніхто не розбереться без архітектора.
Знайомо? Та знайомо, не прикидайтесь. Усі ми проходили через це — швиденько докинути іфку, потім нормально зроблю ж. І от маємо внаслідок
З часом складність та заплутаність лише зростатимуть. І що ж з цим робити?
Розділяйте та володарюйте
Single Responsibility ще ніхто не скасовував. Головне не плутати відповідальність з функціональністю. Це трохи різні речі. Розділяйте, виносьте, інкапсулюйте. Чим чіткіше окреслена відповідальність компонента системи, тим легше з ним працювати, очевидно.
Мисліть сценаріями, а не прапорцями
Кількість можливих комбінацій прапорців зростатиме експоненційно, і настане момент, коли ви просто в них захлинетесь. Якщо всередині компонента усе ж треба різна поведінка в залежності від параметрів, краще визначити стійкі сценарії, комбінації цих параметрів, замість спроб рахувати все всередині.
Логіка компонента — за межами компонента
Складна внутрішня поведінка має право бути. Різні обчислення, композиція даних з різних джерел, умовна логіка — це не зло. Але це все має бути контрольованим, а головне — не змішуватись із представленням. Якщо ваш компонент має лише одне джерело стану, його набагато легше тестувати, а відповідну логіку — оптимізувати і рефакторити.
Ваш компонент — не швейцарський ніж
Якщо він робить усе — він не робить добре нічого. Чим складніша система, тим вірогідніша її відмова. Композиція завжди краща за універсальність. Замість розширювати — розділяйте, замість ускладнювати один компонент — компонуйте з кількох дрібних.
***
Звичайно, сидіти квочкою над кожним рядком коду вам ніхто не каже. То як розпізнати дзвіночки, що компонент починає набирати зайву вагу?
Стає складніше тестувати
В ідеалі ви маєте тестувати компонент на основні простих сценаріїв: успіх, помилка, невизначений стан (завантаження, наприклад). Якщо ви вже починаєте плодити кейси на третій чи пʼятий набір умов — пора задумуватись.
Нова вимога — нова умова
if у такому випадку — ваш найгірший друг. Ніби й може виручити, але це потім вилізе боком. Особисто мені здається, що умовна логіка повинна впливати виключно на композицію, а не складність компонента.
Неможливо описати компонент одним реченням
"Що воно робить?". Якщо ваш компонент це виробництво повного циклу, половину якого ви не розумієте, вітаю — у вас проблеми.
Існує "Режим Х"
В якому компонент поводиться і виглядає на 100% інакше, аніж за замовчуванням. Поведінка має варіюватися, але в жодному разі не відрізнятися кардинально.
***
Ці всі поради не про містичну "чистоту коду", вони про контроль над змінами, над логікою, про те, куди рухаються ваші компоненти, і скільки буде вартувати один прапорець в майбутньому.
Код може бути складним, але у жодному разі не має бути заплутаним.
@babichdev
—
Ну шо, за таке наголосували, чи ні? Чекаю на ваші вподобайки та палку дискусію в коментарях!
Крім вогника можете ще й 50 гривень на збір закинуть.