Keep. It. Simple. Stupid.
Keep. It. Simple. Stupid.
Keep. It. Simple. Stupid.

KISS – акронім для Keep. It. Simple. Stupid (не ускладнюй, дурню) або більш ввічливого keep it short and simple або keep it simple and straightforward (роби коротше та простіше) – принцип проектування, який говорить що найкраще система працює тоді, коли вона проста та зрозуміла. Звідси випливає, що головною задачею при проектуванні є простота і уникнення зайвих ускладнень. Термін KISS особливої популярності набув у 1970-х.

Келі Джонсон сформулював KISS принцип у середині 1900-х, коли працював інженером у Lockheed Skunk Works над програмами розвитку передових літаків.

Переваги KISS

  • Ви можете вирішувати більше задач швидше.
  • Ви можете вирішувати складні задачі кількома рядочками коду
  • Ви можете генерувати код високої якості
  • Ви можете будувати велечезні системи, які легко обслуговувати
  • Ваш код буде більш гнучким, легким для розширення, модифікування чи рефакторингу при нових вимогах
  • Ви можете отримати більше, ніж можете уявити
  • Ви можете працювати у великих групах розробників над великим проектом, адже код дурню зрозумілий

Як я можу застосувати KISS для своєї роботи?

Тут наведено декілька кроків, дуже простих, але в декого можуть виникнути складнощі. Не так просто як здається, залиште все простим, вам знадобиться трошки терпіння.

  • Будь скромним, не думай що ти супер геніальний, це твоя перша помилка.
    Коли ти скромний, в кінцевому підсумку ти станеш геніальним=), а якщо ні, кому яка різниця! Твій код наскільки простий, що не треба бути генієм, щоб його зрозуміти.
  • Розбий своє завдання на під задачі, на кожну з яких ти витратиш не більше 4-12 годин.
  • Розбий свої проблеми на маленькі проблемки. Кожна проблема має вирішуватися одним чи кількома класами.
  • Робіть ваші методи короткими, не більше 30-40 рядків коду кожен. Кожен метод має вирішувати лише одну проблему, а не декілька.
    Якщо у методі багато умов, то слід розділити його на простіші методи.
    Це не лише буде зручно читати і обслуговувати, ви знайдете помилки швидше.
    Ви навчитеся любити  Right Click+Refactor у свому редакторі.
  • Робіть класи простими, за тою ж методологією, що й методи.
  • Вирішіть проблему, потім пишіть код. Немає іншого шляху.
    Багато розробників вирішують проблеми, поки пишуть код, і немає нічого страшного. Насправді можна це робити, але строго дотримуватися вищих правил.
    Якщо у тебе є здібність до розділяння великих проблем на дрібні частини, роби це поки пишеш код. Але не бійся рефакторити код знову і знову, знову і знову. Кінцевий результат має значення, а кількість рядків ні, хоча звісно ми знаємо, що чим менше, тим краще.
  • Не бійся видаляти код. Рефакторинг та рекодинг є дві дуже важливі області. Якщо ти працюєш з новими вимогами, або деякі вимоги були неправильно подані, ти зробиш заново цю задачу в кращий спосіб ніж переробляючи старе рішення.
    Якщо ти дослухаєшся до поради вище, то рекодингу в програмі буде мінімум. А якщо проігноруєш, то переписування коду буде значно більше.
  • І для всіх інших сценаріїв: намагайся бути простим, наскільки це можливо. Це дуже складно, але одного разу це станеться і оглянувшись назад ти не зможеш уявити собі роботу по-іншому!

Напишіть відгук

Ваша пошт@ не публікуватиметься. Обов’язкові поля позначені *