Простота

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

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

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

Знания предметной области

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

Понимание предметной области накапливается в течение работы над проектом. Зачастую более простые решения появляются после какого-то времени работы над проектом.

Наиболее эффективная стратегия — разработка кода только для необходимого в данный момент функционала. Параллельно можно выделить время на изучение предметной области (вместо реализации функционала с опережением). Итерационный рефакторинг позволяет применить накопленные знания к уже написанному коду и упростить его.

Измерение простоты

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

Только конкретная команда на конкретном проекте определяет, что является простым. Однако можно использовать четыре ориентира для определения «простого» кода:

• Testable или тестируемость кода.
  Насколько просто написать автоматизированные тесты для отдельного участка кода? Можно ли учесть как позитивные, так и негативные сценарии?
• Understandable или понятность кода.
  Понятно ли, что делает функция на основании её названия и аргументов? Сколько времени требуется, чтобы понять, что делает написанный код?
• Browsable или удобство навигации.
  Насколько эффективна навигация по кодовой базе в IDE? Как быстро разработчик, который не писал код, может найти необходимое место?
• Explainable или объясняемость.
  Может ли один разработчик объяснить другому, что делает написанный код? Совпадает ли их понимание?