KISS (принцип)
KISS (акроним для «Keep it simple, stupid» — «Делай проще, тупица») — принцип проектирования, принятый в ВМС США в 1960 году[1][2].
Впервые частично встречается в американском английском по крайней мере в 1938 году. Принцип KISS утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей и следует избегать ненужной сложности. Фраза ассоциировалась с авиаконструктором Кларенсом Джонсоном (1910—1990)[3]. В 1970-х годах широко использовался термин «KISS-принцип» (англ. KISS principle)[4]. Вариации на фразу включают (обычно как эвфемизм для более грубого «stupid»): «keep it super simple», «keep it simple, silly», «keep it short and simple», «keep it short and sweet», «keep it simple and straightforward»[5], «keep it small and simple»[6], «keep it simple, soldier», «keep it simple, sailor», «keep it simple, sweetie»[7], «keep it stupidly simple» и «keep it sweet and simple».
Происхождение
[править | править код]По имеющимся сообщениям, акроним был придуман Кларенсом Джонсоном, ведущим инженером Lockheed Skunk Works (создатели Lockheed U-2, SR-71 Blackbird и многих других самолётов)[3].
В то время как уже несколько десятилетий популярно использование расшифровки «Keep it simple, stupid», Джонсон расшифровал KISS как «Keep it simple stupid» (без запятой), и эта трактовка до сих пор используется многими авторами[8] (в английском языке, в отличие от русского, запятая используется для обособления (выделения) обращения достаточно редко). В ней не было никакого скрытого смысла, что инженер был глуп; как раз наоборот[3].
Этот принцип лучше всего иллюстрируется историей, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами. Таким образом, «stupid» относится к отношению между тем, что всё ломается, и сложностью необходимого для этого ремонта.
Акроним часто используется в ВВС США и в области разработки программного обеспечения.
Варианты
[править | править код]Принцип, скорее всего, происходит от похожих концепций, таких как:
- бритва Оккама;
- «Простота есть высшая степень утонченности»[a] Леонардо да Винчи;
- «Меньше — значит больше»[b] Мис ван дер Роэ;
- «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» Йохана Кройфа;
- «Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать»[c] Антуана де Сент-Экзюпери;
- Колин Чепмен, основатель 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».
В разработке ПО
[править | править код]Принцип, запрещающий использование более сложных средств, чем необходимо[10]. Изречение, часто вызываемое при обсуждении вопросов проектирования с целью парирования нарастающей функциональности и управления сложностью разработки. Возможно, связано с изречением Keep It Short and Simple[11]. Принцип декларирует простоту системы в качестве основной цели и/или ценности.
- Меньше - лучше (Less is more)
- Don't repeat yourself (DRY)
- You aren’t gonna need it (YAGNI)
- Эрик Рэймонд в своей книге резюмирует философию UNIX как широко используемый принцип KISS[12]
- Arch Linux
- Slackware Linux
- RISC
- TMTOWTDI
- Разбивайте задачи на подзадачи, написание кода для решения которых не должно, по вашему мнению, длиться более 4—12 часов.
- Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов.
- Делайте ваши методы маленькими. Каждый метод должен состоять не более чем из 30—40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
- Делайте ваши классы маленькими. Здесь применяется та же техника, что и с методами.
- Сначала придумайте решение задачи, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода, и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться правила, обозначенного выше. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё, ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете, что можно ещё меньше/ещё лучше.
- Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения — два важных момента. Если вы столкнулись с новыми требованиями или не были оповещены о них ранее, тогда порой лучше придумать новое, более изящное решение, решающее и старые, и новые задачи.
— Filip Hanik, Senior Software Engineer в SpringSource Division VMware, Inc. Полный текст
См. также
[править | править код]Примечания
[править | править код]- ↑ 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.
- ↑ The Concise New Partridge Dictionary of Slang, Eric Partridge, Tom Dalzell, Terry Victor, Psychology Press, 2007, p.384.
- ↑ 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.
- ↑ 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."
- ↑ 1 2 Kiss principle definition by MONASH Marketing Dictionary (18 ноября 1994). Дата обращения: 24 января 2016. Архивировано из оригинала 30 января 2016 года.
- ↑ Kiss Principle. Дата обращения: 1 октября 2015. Архивировано из оригинала 21 сентября 2011 года.
- ↑ Sunday Post-Crescent (Appleton, WI) 4 ноября, 1973.
- ↑ 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.
- ↑ Everything Should Be Made as Simple as Possible, But Not Simpler | Quote Investigator. Дата обращения: 3 мая 2016. Архивировано 29 мая 2012 года.
- ↑ KISS // Толковый словарь по информатике / Пивняк Г.Г.. — Душ.: Нац. горн. ун-т, 2008. — С. 130. — 599 с. — ISBN 978-966-350-087-4.
- ↑ Kiss principle (англ.). Babylon.com. Дата обращения: 25 июля 2010. Архивировано 18 февраля 2012 года.
- ↑ Eric Raymond. The Unix Philosophy in One Lesson // The Art of Unix Programming. — Addison-Wesley. — ISBN 0-13-142901-9.