KISS (принцип)

У этого термина существуют и другие значения, см. Kiss (значения).

KISS (акроним для «Keep it simple, stupid» — «Делай проще, тупица») — принцип проектирования, принятый в ВМС США в 1960 году^[1][2].

Надпись «Keep it Simple»

Фраза впервые частично встречается в американском английском, по крайней мере, в 1938 году.^{[источник не указан 217 дней]}

Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей и следует избегать ненужной сложности. Фраза ассоциировалась с авиаконструктором Кларенсом Джонсоном (1910—1990)^[3]. В 1970-х годах широко использовался термин «KISS-принцип» (англ. KISS principle)^[4].

Варианты

Вариации на фразу включают (обычно как эвфемизм для более грубого «stupid»):^{[источник не указан 217 дней]}

• «keep it super simple»,^{[источник не указан 217 дней]}
• «keep it simple, silly»,^{[источник не указан 217 дней]}
• «keep it short and simple»,^{[источник не указан 217 дней]}
• «keep it short and sweet»,^{[источник не указан 217 дней]}
• «keep it simple and straightforward»^[5],
• «keep it small and simple»^[6],
• «keep it simple, soldier»,^{[источник не указан 217 дней]}
• «keep it simple, sailor»,^{[источник не указан 217 дней]}
• «keep it simple, sweetie»^[7],^{[уточнить]}
• «keep it stupidly simple» и «keep it sweet and simple».^{[источник не указан 217 дней]}

Происхождение

По имеющимся сообщениям, акроним был придуман Кларенсом Джонсоном, ведущим инженером Lockheed Skunk Works (создатели Lockheed U-2, SR-71 Blackbird и многих других самолётов)^[3].

В то время как уже несколько десятилетий популярно использование расшифровки «Keep it simple, stupid», Джонсон расшифровал KISS как «Keep it simple stupid» (без запятой), и эта трактовка до сих пор используется многими авторами^[8] (в английском языке, в отличие от русского, запятая используется для обособления (выделения) обращения достаточно редко). В ней не было никакого скрытого смысла, что инженер был глуп; как раз наоборот^[3].

Этот принцип лучше всего иллюстрируется историей, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами. Таким образом, «stupid» относится к отношению между тем, что всё ломается, и сложностью необходимого для этого ремонта.^{[источник не указан 217 дней]}

Акроним часто используется в ВВС США и в области разработки программного обеспечения.^{[источник не указан 217 дней]}

Варианты

Принцип, скорее всего, происходит от похожих концепций, таких как:

• бритва Оккама;
• «Простота есть высшая степень утонченности» (итал. La semplicità è l'ultima sofisticazione) — Леонардо да Винчи;
• «Меньше — значит больше» (нем. Weniger ist mehr») — Мис ван дер Роэ;
• «Make Simple Tasks Simple!» — Бьёрна Страуструпа;
• «So the writer who breeds more words than he needs, is making a chore for the reader who reads», — Доктора Сьюза;
• «Playing football is very simple but playing simple football is the hardest thing there is», — Йохана Кройфа;
• «Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать» (фр. Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher) — Антуана де Сент-Экзюпери;
• Колин Чепмен, основатель Lotus Cars, призывал своих дизайнеров: «Simplify, then add lightness».
• Альтернативная точка зрения — «Сделать всё как можно более простым, но не проще» — приписывается Альберту Эйнштейну, хотя это может быть и редакторское изложение своими словами лекции, которую дал Эйнштейн^{[9][неавторитетный источник]}.
• «Simplify, Simplify, Simplify» Стива Джобса, упростившего цитату Генри Дэвида Торо «Simplify, simplify, simplify».
• Норткот Паркинсон сформулировал эту идею как «Третий закон Паркинсона» (ок. 1957): «Expansion means complexity and complexity, decay; or to put it even more plainly—the more complex, the sooner dead».

Машины Робинсона и машина Голдберга, имеющие намеренно чрезмерно усложнённые решения для простых задач или проблем, — юмористические примеры «не-KISS» решений.

«Keep it simple and straightforward» — используемый в маркетинге вариант^[5].

Использование

В анимационных фильмах

Аниматор Ричард Уильямс объясняет принцип KISS в своей книге The Animator’s Survival Kit, и девятка диснеевских стариков также пишут об этом в «The Illusion of Life: Disney Animation». Проблема в том, что неопытные аниматоры «чрезмерно одушевляют» в своих работах, то есть персонаж может двигаться слишком много и делать слишком много. Уильямс призывает аниматоров следовать «KISS».^{[источник не указан 217 дней]}

В разработке ПО

Принцип, запрещающий использование более сложных средств, чем необходимо^[10]. Изречение, часто вызываемое при обсуждении вопросов проектирования с целью парирования нарастающей функциональности и управления сложностью разработки. Возможно, связано с изречением Keep It Short and Simple^[11]. Принцип декларирует простоту системы в качестве основной цели и/или ценности.^{[источник не указан 217 дней]}

• Эрик Рэймонд в своей книге The Unix Philosophy in One Lesson резюмирует философию UNIX как широко используемый принцип KISS^[12]
• Филип Ханик (англ. Filip Hanik) на своей странице сайта Apache Foundation описал принцип KISS в программировании:

• Разбивайте задачи на подзадачи, написание кода для решения которых не должно, по вашему мнению, длиться более 4—12 часов.
• Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов.
• Делайте ваши методы маленькими. Каждый метод должен состоять не более чем из 30—40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
• Делайте ваши классы маленькими. Здесь применяется та же техника, что и с методами.
• Сначала придумайте решение задачи, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода, и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться правила, обозначенного выше. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё, ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете, что можно ещё меньше/ещё лучше.
• Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения — два важных момента. Если вы столкнулись с новыми требованиями или не были оповещены о них ранее, тогда порой лучше придумать новое, более изящное решение, решающее и старые, и новые задачи.

Оригинальный текст (англ.)

{{{2}}}

— Hanik

См. также

• Меньше — лучше (Less is more)
• Don't repeat yourself (DRY)
• You aren’t gonna need it (YAGNI)
• Arch Linux
• Slackware Linux
• RISC
• TMTOWTDI
• Раздутое программное обеспечение
• Это экономика, дурачок
• Мюнцинг
• Опрощение
• Простота