Что такое принцип KISS

Что проверяют

Умеете ли вы удержаться от возможностей языка. Python позволяет метаклассы, подмену атрибутов на лету, декораторы поверх декораторов и трёхэтажные генераторные выражения, и всё это эффектно смотрится на ревью. За вопросом стоит проверка, выбираете ли вы решение по читаемости или по изобретательности.

Как отвечать

Короткое определение: из решений, которые одинаково работают, берётся то, которое дешевле понять следующему читателю. В Python у этого есть местная формулировка, Zen: простое лучше сложного, явное лучше неявного, плоское лучше вложенного.

Пример, где принцип виден сразу:

active = [u for u in users if u.is_active]

Этого достаточно, и не нужен ни filter с lambda, обёрнутый в list, ни класс ActiveUserFilter с методом apply. Что ещё упрощается в реальном коде: dict вместо самописного дерева поиска, стандартный logging вместо своей обёртки, dataclass вместо метакласса, функция вместо класса с единственным методом, ранний выход вместо вложенных условий.

Отдельно скажите про баланс: простое решение обязано оставаться правильным. Если задача требует блокировки, повторов и явной работы с кодировками, убирать их ради красоты нельзя.

Где спотыкаются

Прячут сложность в однострочник. Генераторное выражение на четыре for и два if формально короче, но читается дольше обычного цикла, и отлаживать в нём нечего.

Делают KISS оправданием отсутствию структуры: один модуль на тысячу строк, потому что «так проще». Простота это про понятность, а не про отказ разложить код по местам.

Берут тяжёлую зависимость ради одной функции. Подключить фреймворк, чтобы разобрать дату, проще в момент написания и дороже во всём остальном: обновления, конфликты версий, размер образа.