О важности простоты в программном обеспечении

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

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

… и это будет отстой.

— Хенрик Йоретег (в Твиттере)

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

Давайте рассмотрим пример задачи, решаемой простым и сложным способом. Я собираюсь использовать javascript в качестве языка здесь, но сама концепция не зависит от языка.

Наша цель — написать код, позволяющий складывать два числа.


const addTwoNumbers = (a, b) => a + b

addTwoNumbers(2, 4) 


class Num {
  constructor(num) {
    this.current = num
  }
  set current(num) {
    this.\_current = num
  }
  get current() {
    return this.\_current
  }
  add(num) {
    this.current = this.\_current + num
  }
}

const a = new Num(2)
a.add(b)
a.current 

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

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

Простой код содержит меньше ошибок

Ошибки неизбежны при создании программного обеспечения. Но это не значит, что мы не должны изо всех сил стараться избегать их. Мы нашли много способов сделать это (тестирование, проверка кода, парное программирование и т. д.), и я считаю, что стремление к простоте — еще один из этих способов. Существуют разные способы, с помощью которых простой код может привести к меньшему количеству ошибок:

  • Простой код обычно приводит к меньшему количеству кода; меньше кода — меньше ошибок
  • Простой код легче понять и, следовательно, приводит к более эффективной проверке кода.
  • Легче писать хорошие тесты для простого кода; лучше тесты ≈ меньше ошибок

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

Простой код легче поддерживать

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

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

Что плохого в сложности?

Собственно все. Я уже изложил основные причины выше, но позвольте мне остановиться на некоторых возможностях защиты от сложности программного обеспечения.

«Вы не можете решить сложные проблемы с помощью простого кода. Сложность неизбежна».

Конечно, проблемы могут быть сложными, и некоторые из них также могут потребовать сложных решений. Я по-прежнему считаю, что максимальное упрощение задачи — это хорошо. И если после этого у нас все еще остается сложное решение, возможно, пришло время сделать паузу и подумать:

  • Как мы дошли до такого уровня сложности?
  • Правильно ли мы определили проблему?
  • Есть ли другие проблемы, которые мы можем исправить, чтобы уменьшить сложность?

Мы также можем спроектировать наш код таким образом, чтобы упростить сложное решение (например, путем разделения кода на менее сложные автономные части).

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

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

Справедливо, может быть и так. И если никто, кроме вас, никогда не прикасается к вашему коду, вы можете не слишком беспокоиться о том, насколько легко его понять другим людям. Но я бы предложил вам подумать о своем будущее я как член команды. Может быть, вы немного заржавели в текущем стеке через 2 года. Может быть, вы просто думаете о своем коде как о простом, потому что вы только что написали его.

А может ты прав и твой код является «достаточно просто», что приводит меня к следующей проблеме:

«Когда я узнаю, что мой код достаточно прост? Разве это не совершенно произвольно?»

Хорошая точка зрения. Да, это так. Сложность существует в континууме, и то, где вы проводите линию, зависит от вас/вашей команды. Но я не думаю, что эта линия имеет значение или должна быть проведена.

Вот почему я хотел показать, в каких случаях желательна простота. Вы не хотите стремиться к простоте ради простоты. Вы хотите сделать это из-за многих преимуществ, которые у него есть. Простота — это не флажок, который вы хотите поставить, а скорее одна из многих вещей, над которыми вы хотите работать при написании кода.


Кроме того, простота прекрасна. 😉

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *