← Назад к вопросам

Что такое KISS?

1.0 Junior🔥 161 комментариев
#Архитектура и паттерны

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI26 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

KISS — Keep It Simple, Stupid

Определение

KISS — это принцип разработки, который гласит: избегай ненужной сложности и пиши простой код. Самое простое решение, которое работает — часто лучший выбор.

Суть KISS

  • Простота лучше сложности — решение должно быть понятным
  • Избегай over-engineering — не добавляй функции "на будущее"
  • Понятный код легче поддерживать — новый разработчик быстрее разберётся
  • Меньше кода = меньше ошибок — простой код труднее сломать

Примеры в Android

Плохо — Over-engineering:

// Создание сложной архитектуры для простого случая
interface UserRepositoryFactory {
    fun create(): UserRepository
}

class DefaultUserRepositoryFactory : UserRepositoryFactory {
    override fun create(): UserRepository = UserRepository()
}

class UserViewModel(
    private val factory: UserRepositoryFactory
) {
    private val repository = factory.create()
}

// Для маленького проекта это лишнее!

Хорошо — Просто и понятно:

class UserViewModel(private val repository: UserRepository) {
    // Прямая зависимость, всё ясно
}

Примеры in Android

Плохо — Сложная логика преобразования:

fun processUsers(users: List<User>): List<String> {
    return users
        .asSequence()
        .filter { it.isActive }
        .mapIndexed { index, user ->
            user.copy(id = index).let {
                transformUser(it)
            }
        }
        .groupBy { it.department }
        .flatMap { (_, users) ->
            users.sortedByDescending { it.salary }
        }
        .map { it.name }
        .distinct()
        .take(10)
        .toList()
}

Хорошо — Понятные шаги:

fun processUsers(users: List<User>): List<String> {
    val activeUsers = users.filter { it.isActive }
    val sortedByDept = activeUsers.sortedBy { it.department }
    return sortedByDept
        .sortedByDescending { it.salary }
        .take(10)
        .map { it.name }
        .distinct()
}

KISS в архитектуре

Плохо:

// Много абстракций
interface UseCase<IN, OUT>
interface Presenter<T>
interface Router
interface Interactor
// ...
// 10 интерфейсов для простого экрана

Хорошо:

// Ровно то, что нужно
class UserViewModel(
    private val repository: UserRepository
) : ViewModel() {
    val users = repository.getUsers()
}

KISS при добавлении функций

Плохо — Готовимся к "возможно":

data class User(
    val id: String,
    val name: String,
    val email: String,
    val phone: String,
    val alternatePhone: String,
    val address: String,
    val postalCode: String,
    val country: String,
    val timezone: String,
    val preferredLanguage: String,
    val notificationPreferences: Map<String, Boolean>,
    val subscriptionStatus: String,
    val subscriptionEndDate: LocalDate,
    val loyaltyPoints: Int
    // "на будущее"...
)

Хорошо — Только необходимое:

data class User(
    val id: String,
    val name: String,
    val email: String
)

// Если понадобится — добавим потом

KISS в UI

Плохо — Переусложненный компонент:

@Composable
fun UserCard(
    user: User,
    modifier: Modifier = Modifier,
    onDelete: (User) -> Unit = {},
    onEdit: (User) -> Unit = {},
    onShare: (User) -> Unit = {},
    onFavorite: (User) -> Unit = {},
    cardElevation: Dp = 4.dp,
    cardColor: Color = Color.White,
    textSize: TextUnit = 16.sp,
    // 20 параметров!
) { ... }

Хорошо — Простой и понятный:

@Composable
fun UserCard(user: User, onDelete: (User) -> Unit) {
    Card(modifier = Modifier.padding(8.dp)) {
        Column(modifier = Modifier.padding(16.dp)) {
            Text(user.name)
            Button(onClick = { onDelete(user) }) {
                Text("Удалить")
            }
        }
    }
}

Когда НЕ использовать KISS

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

KISS vs YAGNI vs DRY

ПринципСмыслКогда применять
KISSПиши простоВсегда, по умолчанию
YAGNIНе добавляй ненужноеПри планировании функций
DRYНе повторяй кодПри рефакторинге

Практические правила KISS

1. Один класс = одна ответственность

// Не смешивай логику, UI и данные в одном месте

2. Понятные имена переменных

// Плохо: val d = calculateData()
// Хорошо:
val userData = calculateData()

3. Избегай глубокой вложенности

// Плохо: if (...) { if (...) { if (...) { } } }
// Хорошо: early return

4. Маленькие функции

// Функция должна делать одно — быть понятной с первого взгляда

Вывод

KISS = Программируй для человека, а не для машины

Цель: код, который легко читать, понимать и поддерживать. Если решение требует объяснения — оно слишком сложное.