KISS (принцип)

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

KISS (англ. keep it simple, stupid — буквально — «делай это проще, тупица» или более вежливый вариант англ. keep it short and simple — «делай короче и проще», или keep it stupid simple  «делай чертовски простым») — процесс и принцип проектирования,[1] при котором простота системы декларируется в качестве основной цели и/или ценности. Имеют хождение разные расшифровки этого акронима. Эрик Рэймонд в своей книге резюмирует философию UNIX как широко используемый принцип KISS.[2]

Назначение KISS[править | править вики-текст]

Основной проблемой среди разработчиков ПО сегодня является склонность к усложнению проблемы.

Обычно, когда разработчики приступают к решению технических задач, они разбивают задачу на более мелкие задачи, которые, как им кажется, они понимают, и приступают к написанию кода. Я бы сказал, что 8 или 9 из 10 разработчиков совершают ошибку в том, что не разбивают задачу на достаточно малые задачи доступные для простого понимания. Проявляются такие ошибки обычно в следующем: даже самые простые проблемы имеют очень сложные реализации, спагетти код, чего-нибудь вроде реализаций goto логик в Java классе из 500—1000 строк, методах которые имеют по 100 строк каждый.

Этот блок кода результат того, что разработчик понимает отдельные тонкости первоначальной задачи в ходе написания кода.

Именно от этого пытается уберечь KISS.

Выгоды от KISS[править | править вики-текст]

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

Как применить KISS к коду?[править | править вики-текст]

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

См. также[править | править вики-текст]

Ссылки[править | править вики-текст]

Примечания[править | править вики-текст]

  1. Kiss principle (англ.). Babylon.com. Проверено 25 июля 2010. Архивировано из первоисточника 18 февраля 2012.
  2. Eric Raymond. The Unix Philosophy in One Lesson // The Art of Unix Programming. — Addison-Wesley. — ISBN 0-13-142901-9.