Сложность управляется, а не побеждается

«Простота — великая добродетель, но для ее достижения требуется тяжелая работа и образование, чтобы оценить ее. И что еще хуже: сложность продается лучше». ― Эдсгер Вайб Дейкстра

Разработчикам говорят, что все просто и глупо (KISS), но никто не объясняет, почему код должен быть простым, или преимущества того, чтобы все было глупо.

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

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

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

Совет KISS — это слова, игнорируемые большинством разработчиков, как и совет

Яблоко в день держит доктора подальше

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

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

«Сложность убивает. Это высасывает жизнь из разработчиков, затрудняет планирование, создание и тестирование продуктов, создает проблемы безопасности и вызывает разочарование у конечных пользователей и администраторов». Рэй Оззи

Сложность неизбежна

«Первый шаг любого проекта — сильно недооценить его сложность и трудность». Николл Хант

В статье Фреда Брукса Нет серебряной пули он говорит, что существует два типа сложности.

  • Случайная сложность
  • Существенная сложность

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

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

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

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

Сложность равна ошибкам

Там, где у вас есть сложность, по своей природе могут быть мошенничество и ошибки. Чарли Мангер

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

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

Младшие разработчики/разработчики-ковбои создают сложный код для решения простой задачи

Старшие разработчики создают простой код для сложных задач

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

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

Сложность приносит непонимание, ошибки и путаницу. Сложность делает код, программное обеспечение и решения трудными для понимания. Когда что-то трудно понять, мало кто попытается это понять.

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

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

Сложность кода

Как ошибки попадают в производство даже после того, как кто-то просмотрел код?

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

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

Сложный код делает эту оценку сложной и требует слишком много усилий. Столкнувшись со сложным кодом, вы предполагаете, что он работает, потому что у вас нет времени проверить его.

Время истощает знания

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

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

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

Как справиться со сложностью

Плохие разработчики игнорируют сложность, средние разработчики страдают от нее, а хорошие разработчики избегают ее создания.

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

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

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

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

Уоррен Баффет и Чарли Мангер

«Баффет сказал, что если вы не можете объяснить, почему потерпели неудачу после того, как допустили ошибку, то бизнес был для вас слишком сложным». ― Трен Гриффин, Чарли Мангер: совершенный инвестор

Уоррен Баффет и Чарли Мангер сосредотачиваются на бизнес-возможностях, которые они могут понять, и избегают компаний, которые они не могут понять.

Если они не могут понять компанию, то не инвестируйте в нее. У Баффета и Мангера слишком сложная стопка, и они избегают всего слишком сложного.

"Если что-то слишком сложно, мы переходим к чему-то другому. Что может быть проще?» — Чарли Мангер

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

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