Сложность управляется, а не побеждается
«Простота — великая добродетель, но для ее достижения требуется тяжелая работа и образование, чтобы оценить ее. И что еще хуже: сложность продается лучше». ― Эдсгер Вайб Дейкстра
Разработчикам говорят, что все просто и глупо (KISS), но никто не объясняет, почему код должен быть простым, или преимущества того, чтобы все было глупо.
Простота повышает производительность разработчиков, позволяя разработчикам легче понять, что они делают и какое программное обеспечение они пытаются создать.
Сложность все усложняет. Сложный код вызывает стресс. Вы не знаете, что он делает, и когда вы что-то меняете, он может сломать код в других частях кодовой базы.
Простой код сложнее создать, и на его создание уходит больше времени, а разработчики не поощряются и не вознаграждаются за создание простого кода.
Совет KISS — это слова, игнорируемые большинством разработчиков, как и совет
Яблоко в день держит доктора подальше
Я не вижу, чтобы разработчики ели много яблок или чтобы код оставался простым.
Там, где у вас есть сложность, у вас будут ошибки, ошибки, проблемы, баги и код, который никто не захочет трогать.
«Сложность убивает. Это высасывает жизнь из разработчиков, затрудняет планирование, создание и тестирование продуктов, создает проблемы безопасности и вызывает разочарование у конечных пользователей и администраторов». Рэй Оззи
Сложность неизбежна
«Первый шаг любого проекта — сильно недооценить его сложность и трудность». Николл Хант
В статье Фреда Брукса Нет серебряной пули он говорит, что существует два типа сложности.
- Случайная сложность
- Существенная сложность
Случайная сложность — это сложность, которую разработчики создают и могут исправить. Его дизайн или технический долг, который можно улучшить.
Существенная сложность заключается в том, что если вы хотите, чтобы программа делала много вещей, она будет сложной. Разработчики не могут избежать сложности при создании сложного программного обеспечения. Лучшее, что могут сделать разработчики программного обеспечения, — это попытаться сделать код простым и справиться со сложностью как можно лучше.
Уменьшение случайной сложности плохого дизайна, плохого кода и технического долга. Одна из целей разработчиков программного обеспечения — контролировать сложность и избегать ее создания.
Чем больше сложности создают разработчики, тем сложнее коду будет с ней взаимодействовать. Команды разработчиков с низкими стандартами или без них быстро создадут сложность и технический долг. Воздействие на команду разработчиков займет несколько месяцев, но по мере роста сложности разработка замедляется.
Сложность равна ошибкам
Там, где у вас есть сложность, по своей природе могут быть мошенничество и ошибки. Чарли Мангер
Сложность понимается неправильно, многие разработчики считают сложный код хорошим кодом. Во время создания создается впечатление, что только разработчик, пишущий сложный код, может понять его и создать код.
Правда наоборот, только лучшие разработчики могут создавать простой код.
Младшие разработчики/разработчики-ковбои создают сложный код для решения простой задачи
Старшие разработчики создают простой код для сложных задач
Самый быстрый код для создания — это сложный код. Это первый набросок, где у разработчика не было времени убрать навороты и упростить его. Разработчики могут упростить код только тогда, когда они его понимают.
Сложный код легче и быстрее создать. Цена сложного кода заключается в том, что его сложнее читать, понимать и с ним работать.
Сложность приносит непонимание, ошибки и путаницу. Сложность делает код, программное обеспечение и решения трудными для понимания. Когда что-то трудно понять, мало кто попытается это понять.
Когда что-то трудно понять, люди не могут легко сказать, работает это или нет. Это идеальная почва для ошибок и недоразумений.
Сложный код усложнит жизнь разработчикам в будущем. Итак, Мангер говорит, что именно здесь вы найдете мошенничество и ошибки, потому что трудно понять, как это должно работать.
Сложность кода
Как ошибки попадают в производство даже после того, как кто-то просмотрел код?
Обычный способ проникновения ошибок в код — это не код, который явно неправильный, потому что его было бы легко обнаружить. Это слишком сложный код, и у рецензентов нет времени, чтобы его понять.
Если код прост, рецензент может легко и быстро увидеть, делает ли он то, для чего он предназначен и для чего предназначен.
Сложный код делает эту оценку сложной и требует слишком много усилий. Столкнувшись со сложным кодом, вы предполагаете, что он работает, потому что у вас нет времени проверить его.
Время истощает знания
Когда мы пишем сложный код или создаем сложное решение, мы не думаем о будущем, в котором у нас не будет абсолютного знания о том, как это работает.
Вы понимаете сложный код, когда создаете его, но через 3-6 месяцев код будет казаться, что его создал кто-то другой. В этот момент всем разработчикам будет трудно понять код, даже разработчику, который его создал.
Этот краткосрочный взгляд на код и его понимание приводит к долгосрочным проблемам для команды разработчиков.
Как справиться со сложностью
Плохие разработчики игнорируют сложность, средние разработчики страдают от нее, а хорошие разработчики избегают ее создания.
Чтобы справиться со сложностью разработки программного обеспечения, нужно разбить код на более мелкие части.
Разделение сложности на более мелкие части позволит вам понять ее, спроектировать и закодировать. Разделение требований на более мелкие более простые части дает вам возможность победить сложность.
Сложность — это когда код пытается сделать слишком много вещей одновременно. Когда один фрагмент кода делает много, его трудно изменить. Когда вы меняете что-то одно, это влияет на многие другие вещи, которые вы не можете оценить, будет ли это работать.
Работа со сложностью похожа на работу с техническим долгом. Лучший подход — не создавать его, потому что если он существует, его практически невозможно удалить.
Уоррен Баффет и Чарли Мангер
«Баффет сказал, что если вы не можете объяснить, почему потерпели неудачу после того, как допустили ошибку, то бизнес был для вас слишком сложным». ― Трен Гриффин, Чарли Мангер: совершенный инвестор
Уоррен Баффет и Чарли Мангер сосредотачиваются на бизнес-возможностях, которые они могут понять, и избегают компаний, которые они не могут понять.
Если они не могут понять компанию, то не инвестируйте в нее. У Баффета и Мангера слишком сложная стопка, и они избегают всего слишком сложного.
"Если что-то слишком сложно, мы переходим к чему-то другому. Что может быть проще?» — Чарли Мангер
Программные проекты недооценивают и помещают в легкую кучу, когда они живут в тяжелой стопке. Программное обеспечение для крупных предприятий находится в очень тяжелом состоянии. Это может стоить усилий, но для создания программного обеспечения потребуется больше времени, ресурсов и денег.
Если бы люди знали, что программное обеспечение находится на складе, они могли бы дважды подумать, прежде чем создавать программное обеспечение.