Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

24.09.2024

Виконання вимог клієнтів

У продуктах B2B завжди доводиться робити чимало змін суто через вимоги того чи іншого клієнта. Це абсолютно нормально. Мистецтвом інженера тут є впровадження змін так, щоб не перетворити код в мішанину не повʼязаних шматочків логіки.

В ідеалі можна знайти спосіб узагальнити функціонал. Уявимо платформу для продажу. Наступний клієнт просить додати звіт в якомусь форматі XML. Після дослідження виявляємо, що формат нішевий, але поширений. Чудово — додаємо загальну опцію до експорту звіту, отримуємо нову здібність для нашого продукту.

Але не всі запити можливо або розумно узагальнювати. Не кожне узагальнення корисне. Навіть навпаки — більшість узагальнень тільки все ускладнюють. Легко зрозуміти повністю конкретизований код, або така абстракція, яку можна зрозуміти без конкретного прикладу. Посередині лежать напівузагальнення, які не спираються на специфічні обставини, але потребують їх знання.

Наприклад, новий клієнт — автомагазин — хоче надавати знижку на придбання разом шин та дисків. Можна узагальнити від конкретних категорій, зробити модель на кшталт Знижка(категоріяА, категоріяБ). Ніби корисно. Але чи буде точно така формула потрібна іншим клієнтам? Не впевнений. Гарно було б зробити універсальний рушій правил знижок — гадаю, в реальних платформах таке є. Проте рушій знижок — задача на пару місяців (та ще не зрозуміло, чи вірна.) За першою потребою ми його робити не будемо.

В таких випадках я б краще додав конкретний та стислий блок коду, можливо, навіть з ID клієнта та категорій, та поки не городив би таблиць в базі та іншої архітектури. Зі специфічними змінами легше впоратись, коли вони ізольовані.