KISS (принцип): различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[отпатрулированная версия][отпатрулированная версия]
Содержимое удалено Содержимое добавлено
Нет описания правки
оформление, запросы источника
 
(не показано 13 промежуточных версий 8 участников)
Строка 1: Строка 1:
{{другие значения|Kiss (значения)}}
{{другие значения|Kiss (значения)}}
[[Файл:Keep it Simple.jpg|мини|Надпись «Keep it Simple»]]
'''KISS''' ([[акроним]] для «'''Keep it simple, stupid'''» — «Делай проще, тупица») — принцип проектирования, принятый в [[ВМС США]] в 1960<ref name=TDal/><ref name=EPar/>.
'''KISS''' ([[акроним]] для «'''Keep it simple, stupid'''» — «Делай проще, тупица») — принцип [[Проектирование|проектирования]], принятый в [[ВМС США]] в 1960 году<ref name=TDal/><ref name=EPar/>.


Фраза впервые частично встречается в [[Американский вариант английского языка|американском английском]] по крайней мере в 1938 году.{{Нет АИ|1|01|2025}}
Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности. Фраза ассоциировалась с авиаконструктором [[Джонсон, Кларенс|Кларенсом Джонсоном]] (1910—1990)<ref name=BRich/>. {{nobr|В 1970-х гг.}} широко использовался термин «KISS-принцип» ({{lang-en|KISS principle}})<ref name=Pit/>. Вариации на фразу включают «{{lang-en|Keep it Simple, Silly}}», «{{lang-en2|keep it short and simple}}», «{{lang-en2|keep it simple and straightforward}}»<ref name="monash">{{cite web |url=https://business.monash.edu/marketing/marketing-dictionary/k |title=Kiss principle definition by MONASH Marketing Dictionary |date=1994-11-18 |accessdate=2016-01-24 |archiveurl=https://web.archive.org/web/20160130043650/https://business.monash.edu/marketing/marketing-dictionary/k |archivedate=2016-01-30 |deadlink=yes }}</ref> и «{{lang-en2|keep it small and simple}}»<ref>{{cite web|url=http://people.apache.org/~fhanik/kiss.html|title=Kiss Principle|accessdate=2015-10-01|archiveurl=https://web.archive.org/web/20110921083918/http://people.apache.org/~fhanik/kiss.html|archivedate=2011-09-21|deadlink=yes}}</ref>.

Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей и следует избегать ненужной сложности. Фраза ассоциировалась с авиаконструктором [[Джонсон, Кларенс|Кларенсом Джонсоном]] (1910—1990)<ref name=BRich/>. В 1970-х годах широко использовался термин «KISS-принцип» ({{lang-en|KISS principle}})<ref name=Pit/>.

== Варианты ==

Вариации на фразу включают (обычно как [[эвфемизм]] для более грубого «stupid»):{{Нет АИ|1|01|2025}}
* «{{lang-en2|keep it super simple}}»,{{Нет АИ|1|01|2025}}
* «{{lang-en2|keep it simple, silly}}»,{{Нет АИ|1|01|2025}}
* «{{lang-en2|keep it short and simple}}»,{{Нет АИ|1|01|2025}}
* «{{lang-en2|keep it short and sweet}}»,{{Нет АИ|1|01|2025}}
* «{{lang-en2|keep it simple and straightforward}}»<ref name="monash">{{cite web |lang=en |url=https://business.monash.edu/marketing/marketing-dictionary/k |title=Kiss principle definition |website=Monash Marketing Dictionary |date=1994-11-18 |accessdate=2016-01-24 |archiveurl=https://web.archive.org/web/20160130043650/https://business.monash.edu/marketing/marketing-dictionary/k |archivedate=2016-01-30 |deadlink=yes }}</ref>,
* «{{lang-en2|keep it small and simple}}»{{sfn|Hanik}},
* «{{lang-en2|keep it simple, soldier}}»,{{Нет АИ|1|01|2025}}
* «{{lang-en2|keep it simple, sailor}}»,{{Нет АИ|1|01|2025}}
* «{{lang-en2|keep it simple, sweetie}}»<ref>[Post-Crescent https://archive.org/details/appleton-post-crescent-1973-11-04] (Appleton, WI) Sunday issue, Nov 4, 1973.</ref>,{{уточнить|комм=Укажите номер страницы и статью газеты}}
* «{{lang-en2|keep it stupidly simple}}» и «{{lang-en2|keep it sweet and simple}}».{{Нет АИ|1|01|2025}}


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


В то время как уже несколько десятилетий популярно использование расшифровки «Keep it simple, stupid», Джонсон расшифровал KISS как «Keep it simple stupid» (без запятой) и эта трактовка до сих пор используется многими авторами<ref name=misra>Ram B. Misra (2004), «Global IT Outsourcing: Metrics for Success of All Parties», ''Journal of Information Technology Cases and Applications'', volume 6 issue 3, page 21. [http://web.njit.edu/~jerry/Outsourcing/out-JITCA-6-3-2004-2.pdf Online version] {{Wayback|url=http://web.njit.edu/~jerry/Outsourcing/out-JITCA-6-3-2004-2.pdf |date=20120129095957 }}. Retrieved 2009-12-19.</ref> (в английском языке, в отличие от русского, запятая используется для [[Обращение (лингвистика)#Пунктуация|обособления (выделения) обращения]] достаточно редко). В ней не было никакого скрытого смысла, что инженер был глуп; как раз наоборот<ref name=BRich/>.
В то время как уже несколько десятилетий популярно использование расшифровки «Keep it simple, stupid», Джонсон расшифровал KISS как «Keep it simple stupid» (без запятой), и эта трактовка до сих пор используется многими авторами<ref name=misra>Ram B. Misra (2004), «Global IT Outsourcing: Metrics for Success of All Parties», ''Journal of Information Technology Cases and Applications'', volume 6 issue 3, page 21. [http://web.njit.edu/~jerry/Outsourcing/out-JITCA-6-3-2004-2.pdf Online version] {{Wayback|url=http://web.njit.edu/~jerry/Outsourcing/out-JITCA-6-3-2004-2.pdf |date=20120129095957 }}. Retrieved 2009-12-19.</ref> (в английском языке, в отличие от русского, запятая используется для [[Обращение (лингвистика)#Пунктуация|обособления (выделения) обращения]] достаточно редко). В ней не было никакого скрытого смысла, что инженер был глуп; как раз наоборот<ref name=BRich/>.


Этот принцип лучше всего иллюстрируется историей, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами. Таким образом, «stupid» относится к отношению между тем, что всё ломается, и сложностью необходимого для этого ремонта.
Этот принцип лучше всего иллюстрируется историей, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами. Таким образом, «stupid» относится к отношению между тем, что всё ломается, и сложностью необходимого для этого ремонта.{{Нет АИ|1|01|2025}}


Акроним часто используется в [[ВВС США]] и в области разработки программного обеспечения.
Акроним часто используется в [[ВВС США]] и в области [[Разработка программного обеспечения|разработки программного обеспечения]].{{Нет АИ|1|01|2025}}


== Варианты ==
== Варианты ==
{{орисс в разделе}}
Принцип, скорее всего, происходит от похожих концепций, таких как [[бритва Оккама]], «Simplicity is the ultimate sophistication» Леонардо да Винчи, «Less is more» [[Мис ван дер Роэ, Людвиг|Мис ван дер Роэ]], или «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». Машины Робинсона и [[машина Голдберга]], имеющие намеренно чрезмерно усложнённые решения для простых задач или проблем, — юмористические примеры «не-KISS» решений.
Принцип, скорее всего, происходит от похожих концепций, таких как:
* [[бритва Оккама]];
* «Простота есть высшая степень утонченности» ({{lang-it|La semplicità è l'ultima sofisticazione}}) — [[Леонардо да Винчи]];
* «Меньше — значит больше» ({{lang-de|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», — [[Йохан Кройф Арена|Йохана Кройфа]];
* «Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать» ({{lang-fr|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».
* Альтернативная точка зрения — «Сделать всё как можно более простым, но не проще» — приписывается [[Эйнштейн, Альберт|Альберту Эйнштейну]], хотя это может быть и редакторское изложение своими словами лекции, которую дал Эйнштейн<ref>{{Cite web|lang=en |url=http://quoteinvestigator.com/2011/05/13/einstein-simple/#more-2363 |title=Everything Should Be Made as Simple as Possible, But Not Simpler |website=Quote Investigator |date=2011-05-13 |access-date=2016-05-03 |archive-date=2012-05-29 |archive-url=https://web.archive.org/web/20120529075018/http://quoteinvestigator.com/2011/05/13/einstein-simple/#more-2363 |deadlink=no }}</ref>{{не АИ|комм=ВП:САМИЗДАТ}}.
* «<s>Simplify</s>, <s>Simplify</s>, Simplify» [[Джобс, Стив|Стива Джобса]], упростившего цитату [[Торо, Генри|Генри Дэвида Торо]] «Simplify, simplify, simplify».
* [[Паркинсон, Сирил Норткот|Норткот Паркинсон]]<nowiki/> сформулировал эту идею как «Третий закон Паркинсона» (ок. 1957): «Expansion means complexity and complexity, decay; or to put it even more plainly—the more complex, the sooner dead».


Машины Робинсона и [[машина Голдберга]], имеющие намеренно чрезмерно усложнённые решения для простых задач или проблем, — юмористические примеры «не-KISS» решений.
Альтернативная точка зрения — «Сделать всё как можно более простым, но не проще» — приписывается [[Эйнштейн, Альберт|Альберту Эйнштейну]], хотя это может быть и редакторское изложение своими словами лекции, которую дал Эйнштейн<ref>{{Cite web |url=http://quoteinvestigator.com/2011/05/13/einstein-simple/#more-2363 |title=Everything Should Be Made as Simple as Possible, But Not Simpler {{!}} Quote Investigator<!-- Заголовок добавлен ботом --> |access-date=2016-05-03 |archive-date=2012-05-29 |archive-url=https://web.archive.org/web/20120529075018/http://quoteinvestigator.com/2011/05/13/einstein-simple/#more-2363 |deadlink=no }}</ref>.


«Keep it simple and straightforward» — используемый в маркетинге вариант<ref name="monash"/>.
«Keep it simple and straightforward» — используемый в маркетинге вариант<ref name="monash"/>.
<!-- Эта концепция имеет прямую аналогию с «[[бритва Оккама|бритвой Оккама]]» (например, это в интерпретации [[Эйнштейн, Альберт|Альберта Эйнштейна]] звучит так, что «''Всё следует упрощать до тех пор, пока это возможно, но не более того''»). Тенденцию к поискам возможно более простых решений выдающийся советский математик [[Колмогоров, Андрей Николаевич|А. Н. Колмогоров]] считает универсальным принципом, руководящим работой [[мышление|мышления]] и [[творчество|творчества]]<ref>[http://www.proza.ru/2007/05/13-222 Письмо академика А. Н. Колмогорова (Влад Лившиц) / Проза.ру — национальный сервер современной прозы] </ref>. --> <!--Этот абзац закомментирован, так как без дополнительных вторичных АИ представляет собой Орисс. Подробнее см. СО статьи.-->
<!-- Эта концепция имеет прямую аналогию с «[[бритва Оккама|бритвой Оккама]]» (например, это в интерпретации [[Эйнштейн, Альберт|Альберта Эйнштейна]] звучит так, что «''Всё следует упрощать до тех пор, пока это возможно, но не более того''»). Тенденцию к поискам возможно более простых решений выдающийся советский математик [[Колмогоров, Андрей Николаевич|А. Н. Колмогоров]] считает универсальным принципом, руководящим работой [[мышление|мышления]] и [[творчество|творчества]]<ref>[http://www.proza.ru/2007/05/13-222 Письмо академика А. Н. Колмогорова (Влад Лившиц) / Проза.ру — национальный сервер современной прозы] </ref>. --> <!--Этот абзац закомментирован, так как без дополнительных вторичных АИ представляет собой Орисс. Подробнее см. СО статьи.-->


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


=== В анимационных фильмах ===
== В разработке ПО ==
{{орисс в разделе}}
Принцип, запрещающий использование более сложных средств, чем необходимо<ref>{{книга|часть=KISS|заглавие=Толковый словарь по информатике|ссылка=https://archive.org/details/isbn_9789663500874|ответственный=Пивняк Г.Г.|место=Д.|издательство=Нац. горн. ун-т|год=2008|страницы=[https://archive.org/details/isbn_9789663500874/page/n132 130]|страниц=599|isbn=978-966-350-087-4}}</ref>. Изречение часто вызываемое при обсуждении вопросов проектирования с целью парирования нарастающей функциональности и управления сложностью разработки. Возможно, связано с изречением {{lang-en2|Keep It Short and Simple}}<ref>{{cite web
Аниматор [[Уильямс, Ричард|Ричард Уильямс]] объясняет принцип KISS в своей книге ''The Animator’s Survival Kit'', и [[девятка диснеевских стариков]] также пишут об этом в «[[The Illusion of Life: Disney Animation]]». Проблема в том, что неопытные аниматоры «чрезмерно одушевляют» в своих работах, то есть персонаж может двигаться слишком много и делать слишком много. Уильямс призывает аниматоров следовать «KISS».{{Нет АИ|1|01|2025}}

=== В разработке ПО ===
Принцип, запрещающий использование более сложных средств, чем необходимо<ref>{{публикация|книга|часть=KISS|заглавие=Толковый словарь по информатике|ссылка=https://archive.org/details/isbn_9789663500874|ответственный=Пивняк Г. Г.|место=Д.|издательство=Нац. горн. ун-т|год=2008|страницы=130 |часть ссылка=https://archive.org/details/isbn_9789663500874/page/n132|страниц=599|isbn=978-966-350-087-4}} {{недоступная ссылка}}</ref>. Изречение, часто вызываемое при обсуждении вопросов проектирования с целью парирования нарастающей функциональности и управления сложностью разработки. Возможно, связано с изречением {{lang-en2|Keep It Short and Simple}}<ref>{{cite web
|url = http://dictionary.babylon-software.com/kiss_principle/
|url = http://dictionary.babylon-software.com/kiss_principle/
|title = Kiss principle
|title = Kiss principle
Строка 33: Строка 65:
|archiveurl = https://www.webcitation.org/65XnGGCIE?url=http://dictionary.babylon.com/kiss_principle/
|archiveurl = https://www.webcitation.org/65XnGGCIE?url=http://dictionary.babylon.com/kiss_principle/
|archivedate = 2012-02-18
|archivedate = 2012-02-18
}}</ref>. Принцип декларирует простоту системы в качестве основной цели и/или ценности. [[Рэймонд, Эрик|Эрик Рэймонд]] в своей книге резюмирует [[Философия UNIX|философию UNIX]] как широко используемый принцип KISS<ref>{{книга
}}</ref>. Принцип декларирует простоту системы в качестве основной цели и/или ценности.{{Нет АИ|1|01|2025}}
* [[Рэймонд, Эрик|Эрик Рэймонд]] в своей книге ''The Unix Philosophy in One Lesson'' резюмирует [[Философия UNIX|философию UNIX]] как широко используемый принцип KISS<ref>{{книга|автор=[[Рэймонд, Эрик|Eric Raymond]].|заглавие=The Art of Unix Programming|часть=The Unix Philosophy in One Lesson|ссылка часть=http://www.catb.org/~esr/writings/taoup/html/ch01s07.html|издательство=Addison-Wesley|isbn=0-13-142901-9}}</ref>
|заглавие=The Art of Unix Programming
* Филип Ханик ({{lang-en|Filip Hanik}}) на своей странице сайта Apache Foundation описал принцип KISS в программировании:
|автор=[[Рэймонд, Эрик|Eric Raymond]].
|isbn=0-13-142901-9
|издательство=Addison-Wesley
|часть=The Unix Philosophy in One Lesson
|ссылка часть=http://www.catb.org/~esr/writings/taoup/html/ch01s07.html
}}</ref>.
* [[Чем хуже, тем лучше|Чем меньше, тем лучше]] (Less is more)
* [[Don't repeat yourself]] (DRY)
* [[YAGNI|You aren’t gonna need it]] (YAGNI)

{{начало цитаты}}
{{начало цитаты}}
* Разбивайте задачи на подзадачи, которые не должны, по вашему мнению, длиться более 4-12 часов написания кода
* Разбивайте задачи на подзадачи, написание кода для решения которых не должно, по вашему мнению, длиться более 4—12 часов.
* Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов
* Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов.
* Сохраняйте ваши методы маленькими. Каждый метод должен состоять не более чем из 30-40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
* Делайте ваши методы маленькими. Каждый метод должен состоять не более чем из 30—40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
* Сохраняйте ваши классы маленькими. Здесь применяется та же техника, что и с методами.
* Делайте ваши классы маленькими. Здесь применяется та же техника, что и с методами.
* Сначала придумайте решение задачи, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода, и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться выше обозначенного правила. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё, ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете, что можно ещё меньше/ещё лучше.
* Сначала придумайте решение задачи, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода, и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться правила, обозначенного выше. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё, ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете, что можно ещё меньше/ещё лучше.
* Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения — два важных момента. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое, более изящное решение, решающее и старые, и новые задачи.
* Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения — два важных момента. Если вы столкнулись с новыми требованиями или не были оповещены о них ранее, тогда порой лучше придумать новое, более изящное решение, решающее и старые, и новые задачи.
{{оригинальный текст|en|
{{конец цитаты|источник=Filip Hanik, Senior Software Engineer в SpringSource Division VMware, Inc. <sup>[http://people.apache.org/~fhanik/kiss.html Полный текст]</sup>}}
* Be Humble, don't think of yourself as a super genius, this is your first mistake
By being humble, you will eventually achieve super genius status =), and even if you don't, who cares! your code is stupid simple, so you don't have to be a genius to work with it.
* Break down your tasks into sub tasks that you think should take no longer than 4-12 hours to code
* Break down your problems into many small problems. Each problem should be able to be solved within one or a very few classes
* Keep your methods small, each method should never be more than 30-40 lines. Each method should only solve one little problem, not many uses cases
* If you have a lot of conditions in your method, break these out into smaller methods.
* Not only will this be easier to read and maintain, but you will find bugs a lot faster.
* You will learn to love Right Click+Refactor in your editor.
* Keep your classes small, same methodology applies here as we described for methods.
* Solve the problem, then code it. Not the other way around
* Many developers solve their problem while they are coding, and there is nothing wrong doing that. As a matter of fact, you can do that and still adhere to the above statement.
* If you have the ability to mentally break down things into very small pieces, then by all means, do that while you are coding. But don't be afraid of refactor your code over and over and over and over again. Its the end result that counts, and number of lines is not a measurement, unless you measure that fewer is better of course.
* Don't be afraid to throw away code. Refactoring and recoding are two very important areas. As you come across requirements that didn't exist, or you weren't aware of when you wrote the code to begin with you might be able to solve the old and the new problems with an even better solution.
* If you had followed the advice above, the amount of code to rewrite would have been minimal, and if you hadn't followed the advice above, then the code should probably be rewritten anyway.
* And for all other scenarios, try to keep it as simple as possible, this is the hardest behavior pattern to apply to, but once you have it, you'll look back and will say, I can't imagine how I was doing work before. }}
{{конец цитаты|источник={{sfn0|Hanik}} }}


== См. также ==
== См. также ==
* [[Чем хуже, тем лучше|Меньше - лучше]] (Less is more)
* [[Don't repeat yourself]] (DRY)
* [[YAGNI|You aren’t gonna need it]] (YAGNI)
* [[Arch Linux]]
* [[Slackware|Slackware Linux]]
* [[RISC]]
* [[TMTOWTDI]]
* [[TMTOWTDI]]
* [[Раздутое программное обеспечение]]
* [[Раздутое программное обеспечение]]
* [[Это экономика, дурачок]]
* [[Мюнцинг]]
* [[Опрощение (идеология)|Опрощение]]
* [[Простота]]


== Примечания ==
== Примечания ==
Строка 80: Строка 129:


== Ссылки ==
== Ссылки ==
* {{публикация|статья|язык=en |заглавие=The Kiss Principle |автор=Hanik |автор имя=F. |ответственный=Filip Hanik, Senior Software Engineer, SpringSource Division VMware, Inc. |издание=Filip Hanik, Home page |издательство=Apache Software Foundation |архив=https://web.archive.org/web/20070321064858/http://people.apache.org/~fhanik/ |архив дата=2007-03-21 |ref=Hanik }}
* [https://web.archive.org/web/20110921083918/http://people.apache.org/~fhanik/kiss.html Kiss Principle]
* [http://www.softwaretree.com/v1/KISSPrinciples.html KISS Principles for ORM Products]
* [http://www.softwaretree.com/v1/KISSPrinciples.html KISS Principles for ORM Products]
* [https://habrahabr.ru/post/249639/ KISS — принцип проектирования, содержащий все остальные принципы проектирования]
* ''Толмачёв Д.'' [https://habrahabr.ru/post/249639/ KISS — принцип проектирования, содержащий все остальные принципы проектирования]. — Хабр. — 2015. — 3 января.


{{Внешние ссылки}}
{{Внешние ссылки}}

Текущая версия от 09:26, 1 января 2025

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

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

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

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

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

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

[править | править код]

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

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

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

Акроним часто используется в ВВС США и в области разработки программного обеспечения.[источник?]

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

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

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

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

[править | править код]

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

[править | править код]

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

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

[править | править код]

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

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

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

Примечания

[править | править код]
  1. The Routledge Dictionary of Modern American Slang and Unconventional English, Tom Dalzell, 2009, 1104 pages, p.595, webpage: BGoogle-5F Архивная копия от 24 ноября 2016 на Wayback Machine: notes U.S. Navy "Project KISS" of 1960, headed by Rear Admiral Paul D. Stroop, Chicago Daily Tribune, p.43, 4 December 1960.
  2. The Concise New Partridge Dictionary of Slang, Eric Partridge, Tom Dalzell, Terry Victor, Psychology Press, 2007, p.384.
  3. 1 2 3 Clarence Leonard (Kelly) Johnson 1910—1990: A Biographical Memoir Архивная копия от 10 октября 2015 на Wayback Machine (PDF), by Ben R. Rich, 1995, National Academies Press, Washington, DC, p. 13.
  4. Pit & Quarry, Vol. 63, July 1970, p.172, quote: "as in every other step of the development process, follow the KISS principle — Keep It Simple, Stupid."
  5. 1 2 Kiss principle definition (англ.). Monash Marketing Dictionary (18 ноября 1994). Дата обращения: 24 января 2016. Архивировано из оригинала 30 января 2016 года.
  6. Hanik.
  7. [Post-Crescent https://archive.org/details/appleton-post-crescent-1973-11-04] (Appleton, WI) Sunday issue, Nov 4, 1973.
  8. Ram B. Misra (2004), «Global IT Outsourcing: Metrics for Success of All Parties», Journal of Information Technology Cases and Applications, volume 6 issue 3, page 21. Online version Архивная копия от 29 января 2012 на Wayback Machine. Retrieved 2009-12-19.
  9. Everything Should Be Made as Simple as Possible, But Not Simpler (англ.). Quote Investigator (13 мая 2011). Дата обращения: 3 мая 2016. Архивировано 29 мая 2012 года.
  10. KISS // Толковый словарь по информатике / Пивняк Г. Г.. — Д. : Нац. горн. ун-т, 2008. — С. 130. — 599 с. — ISBN 978-966-350-087-4.  (недоступная ссылка)
  11. Kiss principle (англ.). Babylon.com. Дата обращения: 25 июля 2010. Архивировано 18 февраля 2012 года.
  12. Eric Raymond. The Unix Philosophy in One Lesson // The Art of Unix Programming. — Addison-Wesley. — ISBN 0-13-142901-9.