Принимай всё, не понимая ничего

Нажать Enter, чтобы принять предложение кода, проще, чем прокручивать мимо него. Одно нажатие клавиши — и код ваш. Но чтение и понимание этого кода не стали происходить быстрее.

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

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

В 1974 году Брайан Керниган сказал, что отладка в два раза сложнее, чем написание программы. Он говорил о коде, написанном людьми. По крайней мере, люди понимают свою собственную работу.

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

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

Это создает реальные проблемы:

• Вы отлаживаете код, который никогда не читали. Когда что-то ломается спустя недели, вы начинаете с нуля.
• Сбоят граничные случаи. Предложение хорошо обрабатывает основной сценарий (happy path). В нем есть проверка на null. Но оно упускает специфическую логику, необходимую вашему бизнесу.
• Вы не можете защитить свои pull requests. Если ревьюер спросит, почему вы выбрали именно этот метод, у вас не будет ответа. Вы не принимали это решение. Вы просто не отклонили его.

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

Для шаблонного кода (boilerplate) или быстрых скриптов скорость — это нормально. Но для бизнес-логики или безопасности ваш подход должен измениться. Читайте код так, будто вы будете за него отвечать. Потому что так оно и будет.

Вместо этого делайте следующее:

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

Нажатие клавиши стало дешевле. Ваша ответственность — нет. Скорость без понимания — это просто быстрый способ накопить долг.

Source: https://dev.to/cloudx/accept-all-understand-none-4dob

Optional learning community: https://t.me/GyaanSetuAi