Вы когда-нибудь смотрели на код и съеживались? За каждой строкой кода, который когда-либо создавался, стоит какая-то мысль. Плохой код возникает из-за отсутствия понимания проблемы и опыта. Чем больше вы понимаете проблему, тем лучше ее решение.

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

Я занимаюсь программированием с 1988 года. Ранее в этом году я перешла на 50-й язык программирования. Я работал со многими, многими программистами. Некоторые хорошие, некоторые, кхм, не очень. Я видел десятки десятков стилей. И список продолжается. По большей части мне очень понравилась моя карьера. Но больше всего меня расстраивает наследование дрянного кода. Я первым признаю, что написал дрянной код. У всех разработчиков есть. Если вам нужно вернуться к своему коду через 6 месяцев и вам интересно, о чем вы думали, когда писали его, то пора перейти на тупой код. Конечно, лучше с самого начала писать Тупой код.

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

Dumb Code придерживается следующей методологии:

  1. Найдите простейшее элегантное решение для достижения конечного результата проблемы.
  2. Как можно лучше понять проблему.
  3. Разбейте более крупные части кода на более мелкие компоненты, которые выполняют одно задание.
  4. Пишите простой, чистый, понятный код.
  5. Держитесь подальше от причудливых языковых конструкций.
  6. Рефакторинг. Рефакторинг. Рефакторинг.
  7. Хорошо документируйте код в областях, которые могут вызвать путаницу.
  8. Напишите модульные тесты для проверки ваших компонентов.

Ни одна из этих концепций не нова. Они включены во многие методологии. Но каждый раз, когда вы пишете код, вы должны спрашивать себя, является ли то, что вы написали, тупым кодом. Если вы можете сказать «да», переходите к следующему заданию. Если ответ отрицательный, начинайте рефакторинг, пока не почувствуете, что он достиг вершины тупого кода.