Принцип KISS - Keep It Simple, Stupid

Принцип KISS был разработан ВМС США в 1960 году.

Он гласит: простые системы будут работать лучше и надежнее.

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

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

Перефразирую социального психолога Гюстова Лебона:

Мамонта нужно есть по кусочкам

Пример

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

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

Для решения декомпозиции комплексной задачи следует использовать принцип DDD(Domain-driven design).

Причина появления

• Низкая квалификация разработчика
• Когда обучение происходит на базе онлайн-курсов, а не фундаментальных знаний/книг
• Когда нет системного мышления
• Когда сроки реализации функциональности сокращены доне́льзя

Почему сложные решения - это плохо

1. Сложность сопровождения
• Нужно затрачивать ощутимо больше времени на перечитывание сложного кода
• Страх у другого разработчика менять код, который он не понимает или понимает плохо
2. Стоимость разработки/сопровождения
• Нужно потратить ощутимо больше времени для понимания и потом для изменения кода, а время разработчика стоит дорого
3. Когнитивное усложнение кода
• Так уж устроен наш мозг, что после когнитивно сложной задачи ему нужно немного отдохнуть. В течение времени, который мозг выделил себе на отдых, а это делает именно мозг, а не воля его владельца, его владелец не сможет эффективно переключить его работу на новую задачу, как следствие, владелец начинает прокрастинировать.

Как обнаружить проблему

• Если для понимания кодовой базы не достаточно бегло пробежать глазами по нему, требуется перечитывать или доставать старый ойуунский бубен и стучать в него;
• Если функция/метод содержит больше 50 строк (тут важна не сама цифра, а понимание порядка);
• Если функция/метод состоит из 5 аргументов (тут тоже цифра может изменяться в зависимости от ЯП, для низкоуровневых языков и 3 аргумента может оказаться сложным)
• Если код необходимо пояснять комментариями
• Когда требуется открыть большое количество скриптов, чтобы понять реализованную функциональность
• Когда сопровождение и/или развитие кодовой базы требует значительного вложения человеко-часов

Как исправить проблему

• Разбить код на небольшие короткие блоки, которые выполняют простые атомарные действия
• Сложный код разбить на группу простых функций/методов
• Провести рефакторинг наименования, дать говорящие названия (функции/методы должны говорить, что они делают и в каком контексте, например: getUserByEmail вместо userEmail, переменные должны иметь понятные читаемы названия и не требовать комментариев, например: sortedUsersByLastVisit вместо users)
• Воспользоваться статичтическими анализатора кода с максимально чувствительными настройками и исправить код по его рекомендациям
• Просканировать кодовую массу анализаторами, которые рассчитывают cyclomatic complexity и cognitive complexity
• Запросить code review у коллег или друзей, чтобы получить альтернативное мнение о коде

Подходов и решений для профилактики данной проблемы много, главное помнить о необходимости придерживаться данного принципа.