«У меня не было времени кодировать это правильно».
«Это не входит в задачи этого спринта».
«Я не писал этот код, так что это не моя проблема».

Оправдания, оправдания. Будучи техническим руководителем, я много раз слышал эти оправдания от программистов, пытающихся обойти сложные задачи. Может быть очень неприятно слышать, что вещи, которые, как вы знаете, приведут к плохому качеству кода: код, который будет вонючим, код, который вызовет технический долг, или код, который необходимо будет рефакторить в будущем. Это разочарование стало одной из основных причин, по которой я написал книгу Ленивые программисты: хорошие, плохие, злые.

Недавно на YouTube такое же разочарование выразил разработчик Handmade Hero, Casey Muratori. Кейси выразил разочарование многочисленными оправданиями, которые ему давали по поводу того, почему терминал Microsoft работает так медленно. Итак, он написал свою собственную версию за несколько дней, которая разоблачила все эти оправдания как пустые и печальные комментарии по поводу того, что наша профессия принимает такой плохой код. Одним из оправданий, которые он слышал, было вам придется переписать ВЕСЬ код, чтобы исправить низкую производительность. Как доказал Кейси, в большинстве случаев это просто ложь. На самом деле, в проекте больших данных, который я поддерживаю, я часто шучу, что мы находимся на нулевом уровне оптимизации, то есть Не делай глупостей! Результат очистки ужасно спроектированного кода с помощью простых механизмов, таких как кэширование, часто приводит к повышению производительности на порядок.

Это возвращает меня к тому, что побудило меня написать книгу о ленивом программировании — честно рассмотреть спорный вопрос со всех сторон. Многие программисты, такие как Ларри Уолл из Perl, считают ленивое программирование достоинством. С другой стороны, есть столько же блоггеров и ютуберов, которые яростно выступают против этого, сосредотачиваясь на традиционном определении лени как избегания работы. Помимо подробного анализа аргументов (с примерами, демонстрирующими все пункты), книга стремится повысить наш уровень профессионализма. Но мы должны пойти дальше и спросить: «Почему мы должны быть профессионалами?» Почему оправдания, перечисленные в начале этой статьи, являются оскорблением этого профессионализма? Ответ заключается в том, что мы поддерживаем наше стремление к совершенству с определенной целью. Итак, какова наша цель в написании кода? Вот одна из причин, приведенная в главе 4:

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