Два моих принципа разработки: KISS и YAGNI

Я пишу на разных языках и развиваю собственный стартап. За годы практики перепробовал много методик, шаблонов и фреймворков. В конце концов я понял, два главных моих принципа разработки это KISS и YAGNI. Без них сложные архитектуры и «фичи на вырост» съедают время, бюджет и мотивацию.

KISS (Keep It Simple, Stupid)

Суть принципа предельно проста:

Решение должно быть максимально простым из всех возможных.
Не «красивым», не «гибким», не «архитектурно правильным», а простым.

Программисты обожают строить сложные абстракции там, где достаточно обычного условия if. KISS призывает выбирать самое простое и прямолинейное решение задачи.

Код должен читаться так же легко, как пишется. Каждый модуль решает одну задачу, зависимости явные, абстракции оправданы реальной сложностью, а не привычкой.

Особенно сейчас работая над стартапом я понимаю: простота = скорость итераций + меньше багов.

Как применять?
Если ты можешь решить задачу без введения нового паттерна или сторонней библиотеки — сделай это. Читаемость важнее «умности» кода.

Всегда задавайте себе вопрос: Можно ли сделать это ещё проще, не потеряв в функциональности?

Не нужно:

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

YAGNI (You Aren’t Gonna Need It)

Суть принципа:

Тебе это не понадобится.

Этот принцип отлично дополняет KISS, это борьба с избыточным проектированием.

Часто мы пишем код «на будущее»: «А вдруг нам завтра понадобится поддержка еще пяти типов баз данных?» или «Добавлю-ка я этот метод, вдруг пригодится».

Например, в стартапе задачи меняются каждые 1–2 недели. Делай только то, что нужно сейчас!

Как применять?
Реализуй функционал только тогда, когда он нужен. Не пиши код для гипотетических задач.

Понадобится — добавите. И добавите уже понимая реальную задачу, а не воображаемую.

Не нужно делать:

• абстрактные репозитории «на будущее»
• интерфейсы под один класс
• универсальные методы, которые используются в одном месте
• гибкую конфигурацию, которая никогда не меняется
• сложная система ролей, когда есть всего 2 типа пользователей

Почему именно они?

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

Неопытный разработчик пишет плохо, потому что не умеет.

Опытный — потому что слишком много знает и пытается применить всё сразу.

Именно здесь KISS и YAGNI выступают как «тормоз», который не даёт вам переусложнить систему. Код, который не написан, не ломается. Код, который прост, легче рефакторить, когда бизнес-требования всё-таки меняются.

Они заставляют:

• не городить лишнего
• не фантазировать о будущем
• не усложнять ради «правильности»

Пример: Логика получения данных пользователя

❌ Как делать НЕ надо (Overengineering)

Здесь мы заранее создаем интерфейсы, фабрики и закладываем «гибкость» там, где она не просилась.

// Слишком сложно для простой задачи (Нарушение KISS/YAGNI)
type UserProvider interface {
    GetByID(id int) (*User, error)
}

type MySQLProvider struct {
    db *sql.DB
}

func (m *MySQLProvider) GetByID(id int) (*User, error) {
    // реализация
}

func NewUserProvider(dbType string) UserProvider {
    if dbType == "mysql" {
        return &MySQLProvider{}
    }
    return nil
}

Проблема: Если у тебя в проекте всего одна база данных и один способ получения юзера, этот код — мусор. Ты потратишь время на поддержку интерфейса, который ничем не оправдан.

✅ Как сделать по KISS и YAGNI (Best Practice)

Пишем ровно то, что нужно для работы приложения сейчас.

// Просто и понятно
type UserService struct {
    db *sql.DB
}

func (s *UserService) GetUser(id int) (*User, error) {
    var u User
    err := s.db.QueryRow("SELECT id, name FROM users WHERE id = ?", id).Scan(&u.ID, &u.Name)
    return &u, err
}

Почему это лучше:

1. Читаемость: Любой разработчик сразу видит, откуда берутся данные.
2. YAGNI: Мы не гадаем, будет ли у нас PostgreSQL или MongoDB через год. Если понадобится — отрефакторим.
3. KISS: Код прямолинеен, его легко отладить.

Вывод

Прежде чем создать новый интерфейс или структуру, спроси себя: «Могу ли я сделать это проще?» и «Нужно ли это мне именно сегодня?». Если ответ «да» и «нет» — удаляй лишнее.