Некоторое время назад я говорил на забавную тему: комментарии, как запах кода. Я получил изрядное количество дискуссий и встречных точек зрения от читателей по этой теме. Фактически, один фантастический читатель Патрик Майклсен дошел до того, что написал хорошо продуманное опровержение.

При разработке кода мы часто обсуждаем идеальные практики. Хотя я могу указать на то, что к идеалу нужно стремиться, даже если вы никогда его не достигнете (например, без комментариев), есть другой вопрос, который я хочу обсудить сегодня.

Это концепция Perfect vs Good Enough. Это суть многих аргументов против различных идей создания кода.

Это аргумент в пользу того, что код, который мы пишем, «достаточно хорош», а попытки его усовершенствовать - пустая трата времени (мы полностью игнорируем высокую субъективность термина «достаточно хороший»). Я считаю, что этот аргумент попадает в ловушку, в которую попадает большинство из нас, когда пишут код.

Это недостаточно серьезно для общей жизни нашего кода. Помните 2000 год? (Если не в Google, это хорошая история). Большинство затронутых систем были написаны за 30-40 лет до того, как проблема 2000 года стала проблемой. И продолжительность жизни измеряется не только в календарном времени, или, иначе говоря, «это не просто годы, это мили». Если бы мы могли отслеживать одну функцию в приложении и подсчитывать каждый раз, когда она читается разработчиком, а не каждый раз, когда она модифицируется, мы бы обнаружили десятки и даже сотни операций чтения для каждой модификации.

Это означает, что оптимизация для «чтения», а не «записи» нашего кода в 100 раз эффективнее.

На это можно взглянуть по-особенному. И это концепция КОГДА. Когда вы хотите работать? Мы можем легко написать наш код максимально быстро. Для этого мы пожертвуем качеством кода. Это по-прежнему означает, что мы потратили меньше времени на написание кода. Но было бы неправильно сказать, что мы сократили объем выполняемой работы. Вместо этого мы просто перекладываем работу с «сейчас» на «позже». Это часто называют «техническим долгом». Но этого срока недостаточно. Считать работу неизбежной - полезная парадигма. Особенно в сочетании с тем фактом, что чем дальше мы вносим изменения, тем они дороже.

Например, изменение функциональности нашей системы почти бесплатно, если мы сделаем это до того, как сделаем ЛЮБУЮ работу. Чем больше мы выполняем работы (совещания по проектированию, документы и, в конечном итоге, код), тем дороже вносятся изменения. Самые дорогие изменения - это те изменения, которые мы вносим спустя годы после запуска системы в производство. Будь то ошибки или новые функции, эти изменения неизменно на порядки дороже.

Теперь реальность такова, что мы можем легко потратить много времени на оптимизацию кода для удобства чтения и качества и никогда не получить от этой работы никакой пользы. Возможно, мы никогда больше не прикоснемся к этой системе. Это может никогда не получить ошибку. И, к сожалению, мы не можем заглядывать в будущее и видеть, какие ошибки мы исправим и какие изменения внесем в течение всего жизненного цикла нашего приложения. Если бы мы могли это сделать, мы также могли бы оплачивать автостраховку только в те месяцы, когда мы попадаем в аварию, и нам нужно было бы начать полис страхования жизни только в месяц, когда мы умираем (насколько это болезненно?).

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

Так что в следующий раз, когда у вас возникнет соблазн срезать угол, пропустить модульные тесты или оставить менее читаемый алгоритм без рефакторинга, подумайте, когда вы хотите выполнить эту работу и в какой ее части. Работа, которую мы делаем сегодня для улучшения качества нашего кода (независимо от конкретных методов, которые мы используем), - это работа, которой мы не займемся завтра.

Не забудьте пройти все наши замечательные курсы по JavaScript, Node, React, Angular, Vue, Docker (один из моих любимых) и т. Д.

Удачного кодирования!

Нравится это обсуждение? Подпишитесь на нашу рассылку здесь.

Приходите к нам: thinkster.io | Facebook: @gothinkster | Twitter: @GoThinkster