Я хочу, чтобы вы задумались над этим вопросом: вы когда-нибудь застревали, пытаясь понять, почему фрагмент кода не работает? Раньше это работало, а теперь в один миг сломалось, и вы не представляете, почему это произошло. Мы пишем этот код, потом он ломается, и мы чешем затылки, не в силах понять, почему он не работает.

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

Я думал, что так обстоят дела. Мы не знаем, что мы делаем как программисты. Мы все просто летим.

Однако теперь я считаю, что это признак одной из тех более глубоких и более универсальных проблем.

Представьте, что вы не можете пройти модульный тест, поэтому вы заключаете его в круглые скобки, добавляете один плюс и оборачиваете его try-catch. А потом он просто случайно срабатывает. Тест проходит. Тогда ты такой: позволь мне вернуться и просто надейся, что это не сломается. Вы даже поместили туда небольшой комментарий к коду, например

«Не трогай это. Я едва могу заставить его работать. Я не знаю, почему это работает, но давайте просто отправим это таким образом».

Правда в том, что если вы не знаете, почему ваш код работает, у вас нет шансов исправить его, когда он сломается, кроме как по чистой случайности и догадкам. Тем не менее, мы часто это делаем. Мне нравится называть это профессиональным угадыванием. Это все, что мы делаем. Единственная профессия, которая, как я определил, сходит с рук профессиональными предположениями, — это прогнозирование погоды.

Тем не менее, должна ли наша профессия быть такой? Должны ли мы просто отправить код и сказать нашему боссу, что эта функция готова? И все же мы мало или совсем не верим в его способность поддерживать свою функциональность, и мы понятия не имеем, почему он это делает.

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

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

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

Как вы думаете, сколько строк кода работает сегодня по всему миру? Правильного ответа нет, но скажем, сотни миллиардов, это много кода. У меня есть еще один вопрос к вам. Сколько нулей нам нужно добавить к этому числу, каким бы оно ни было, чтобы учесть все строки кода, которые были переписаны? не раз, не два, не десять раз, а сотни раз.

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

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

Я хочу сказать, что нам часто бывает трудно понять код, потому что мы не можем или не хотим настаивать на том, чтобы наши идеи передавались через код. Проблема в том, что мы пишем наш код в первую очередь для компьютеров.

И у меня для вас новость: исходный код предназначен не для этого, понятно?

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

В теории информатики нам говорят, что существует бесконечное количество способов написать одну и ту же программу в пределах программ, которые, по крайней мере, кажутся делающими то, что мы хотим в данный момент.

Внутри самого JavaScript одна и та же программа может быть структурирована бесконечным числом способов. Это действительно удивительно, потому что это огромное число. В некотором смысле кажется, что должно быть фиксированное количество способов написать одну и ту же программу, но с математической точки зрения возможности бесконечны. Как бы мы решили, что является лучшим вариантом среди всех этих вариантов? Какой показатель мы будем использовать? Большинство людей используют самый быстрый, верно? Самый быстрый код — лучший.

Самый быстрый код экономит нам миллион долларов дохода за четверть миллисекунды. Вот только мы даже не понимаем, что значит писать более быстрый код. Мы понятия не имеем, что делают компиляторы. Мы даже не понимаем, что они делают, когда мы что-то подправляем и делаем ++i вместо i++. Вы сделали ++i вместо i++, потому что где-то видели тест jsPerf, в котором говорилось, что он на одну десятую наносекунды быстрее. Таким образом, вы помещаете его во все свои циклы for. И где-то был тест, в котором говорилось, что мы должны кэшировать длину наших массивов, прежде чем зацикливаться на них. Но оказывается, что бы вы ни выбрали, это не более чем подсказка компьютеру.

Это то, что мы начали делать в 1960-х годах, когда изобрели языки программирования. Именно тогда программисты перестали ставить единицы и нули на перфокарты и начали символически представлять программы. Но мы добились абстракции или разделения между написанным нами кодом и точными инструкциями, которые использовал компьютер. За последние 60 лет мы стали все больше и больше отдаляться друг от друга. Теперь, когда вы пишете код React, он даже не похож на точные инструкции, которые выполняются на компьютере.

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

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

Знаете, что мне интересно?

Сколько строк вашего кода переживет этот неизбежный цикл, когда кто-то пытается исправить ошибку или что-то расширить и находит ваш код. Сколько из тех строк кода, которые вы написали, переживут то, что «было бы быстрее, если бы я переписал его цикл»?

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

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

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

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

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

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

Вместо этого говорят, что вот этот новый фреймворк, который занимает в два раза больше строк кода, но вот насколько он понятнее.

Почему мы никогда не видим, чтобы кто-нибудь пытался оптимизировать для удобочитаемости?

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

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

А теперь предупреждение. Предупреждение о том, что я собираюсь вас обидеть. Но это из лучших побуждений, хорошо?

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

Мы оптимизируем каждый процесс, чтобы быстрее писать больше кода. Итак, мы производим все больше и больше кода, который никто не может понять, кроме компьютера.

Я хотел бы завершить это несколькими практическими рекомендациями. т. е. рефакторинг вашего кода

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

Просто выделите шесть минут из каждого часа. Нет нужды тратить весь день на размышления об имени переменной. Вместо этого, возможно, вы можете уделять шесть минут каждый час, чтобы просмотреть код, который вы написали за предыдущие 54 минуты, и спросить себя: «Имеет ли смысл это имя переменной?»?

Вот мой трюк. Всякий раз, когда я смотрю на один из фрагментов кода, который я написал, это довольно ужасно, я сразу же задаю себе вопрос: попробуйте представить, если бы мне пришлось преподавать это в классе. Как бы это выглядело, и какие вопросы я бы получил от людей, если бы пытался объяснить это людям, и это обычно моя главная подсказка. Я недостаточно хорошо понимаю этот код, и он нуждается в доработке, и это не будет сделано так, это потребует многократных правок снова и снова. Я возвращаюсь к своему коду, снова, и снова, и снова, и снова, почти навязчиво спрашивая, есть ли в нем смысл? Я хотя бы отдаленно делюсь своими идеями?

В этом вся суть. Помните, я сказал, что мы сталкиваемся с экзистенциальным кризисом и пытаемся конкурировать с компьютером, чтобы лучше справляться с тем, для чего он предназначен? Вот одна вещь, в которой мы всегда будем преуспевать в чутком общении с другими людьми.

Мы должны сосредоточиться на этом, потому что это единственное, что всегда будет отделять нас от компьютера, и если это перестанет отделять нас от компьютера, мы могли бы также упаковать его, потому что с этим покончено.

Надеюсь, некоторые из этих мыслей заставили вас переосмыслить, куда вы вкладываете свои усилия в свой код. Может быть, они предложили вам обсудить с вашими командами, чего мы на самом деле пытаемся достичь? Можем ли мы сотрудничать вместе, можем ли мы работать вместе и можем ли наши идеи эффективно передаваться друг другу? Действительно ли мы хотим, чтобы компьютер что-то делал? Или мы пытаемся сделать процесс, который работает для всех нас?

Только тогда работа, которую вы делаете каждый день, будет иметь значение.

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