Когда мы забываем, что код также предназначен для чтения людьми, мы получаем пугающие кодовые базы, которые заставляют будущих сопровождающих выдергивать волосы.
Я большой поклонник Эйприл Венсель и ее разговоров о кодексе сострадания. Мне нравится, как она доводит до конца, что разработка программного обеспечения - это работа с другими людьми. Да, невероятно важно, чтобы у нас был технический опыт, но мы также должны быть экспертами в сотрудничестве.
Для эффективного сотрудничества нам нужны инженеры с высоким уровнем эмоционального интеллекта. И хотя это, безусловно, означает снижение токсичности на рабочем месте, эмоциональный интеллект распространяется и на код, который мы пишем. Это то, что мы исследуем в этой статье - написание кода с учетом эмпатии.
Но как код может быть чутким?
Хороший вопрос. В конце концов, мы часто думаем об эмпатии как о чем-то, связанном с нашим взаимодействием с другими людьми, и мы думаем о коде как о времени, когда мы становимся «чисто техническими».
Однако, как авторы кода, который мы пишем, у нас есть возможность проявить сочувствие к будущим сопровождающим нашего кода. Когда мы пишем код, который учитывает то, как будущие сопровождающие будут чувствовать его, читая его, мы подходим к своей работе по-другому. Внезапно стало меньше просто заставлять вещи работать или выталкивать функцию за функцией. Вместо этого мы начинаем заботиться о ремонтопригодности, удобочитаемости и простоте.
Есть знакомая программная цитата из Code For The Maintainer, в которой подчеркивается этот аспект сочувствия (наряду с небольшой мелодрамой).
Всегда кодируйте так, как будто человек, который в конечном итоге поддерживает ваш код, является жестоким психопатом, который знает, где вы живете.
Что мне нравится в этой цитате, так это то, что она задействует наш инстинкт выживания, чтобы напомнить нам, что важно думать о людях будущего, которые будут поддерживать код, который мы пишем сегодня. Иногда этот будущий сопровождающий - это вы, иногда - кто-то, с кем вы никогда не встречались. И хотя будущий сопровождающий редко собирается преследовать вас с убийственными намерениями, они все же остаются людьми. Жизненно важно, чтобы мы писали код, который делает их работу радостью, а не суетой.
Итак, как нам написать чуткий код?
Многие в индустрии программного обеспечения любят идею чистого кода, впервые представленную Робертом Мартином в его книге Чистый код. И хотя мне нравится масса этих принципов чистого кодирования, я думаю, что мы многое упускаем, если сосредотачиваемся только на лучших практиках или правилах списка, чтобы сделать наш код чистым или нечистым.
Вместо этого я думаю, что для нас важно представить эти «передовые методы» программного обеспечения через призму сочувствия и то, как они влияют на людей, которые потребляют наш код (возможно, другие разработчики используют API внутреннего модуля) или вносят обновления в наш код. Таким образом, он становится не столько контрольным списком вещей, которые мы «должны делать», но и более закрепленными в способе, которым мы делаем что-то.
Давайте кратко рассмотрим некоторые из этих приемов работы с программным обеспечением через призму сочувствия:
Автоматизированные тесты
Тесты - отличный способ обеспечить долгосрочную безопасность модуля кода. Автоматически проверяя, что код работает, они служат одной из первых линий защиты от дорогостоящих ошибок и регрессов. Когда я открываю файл в первый раз и вижу, что он полностью покрыт тестами, я чувствую полную свободу вносить любые изменения, которые мне нужны - без страха что-то сломать! Напротив, открытие файла без каких-либо тестов может быть совершенно ужасным. Когда мы пишем тесты, мы не только экономим время и деньги для нашего бизнеса, мы заботимся о том, чтобы будущий сопровождающий нашего кода мог чувствовать себя в безопасности, изменяя его.
Единый стиль
Наличие единообразного стиля кода значительно облегчает жизнь будущим сопровождающим. Проблемы с синтаксисом и форматированием, как правило, незначительны, и их обычно можно автоматизировать с помощью таких инструментов, как ESLint и Prettier (если вы пишете JavaScript, для других языков вам могут потребоваться другие инструменты).
Наличие единообразного стиля кода чутка, потому что позволяет вашим товарищам по команде быстрее понять код. Отсутствие принуждения их тратить лишние мозговые циклы на чтение непоследовательно отформатированного кода позволяет им сосредоточиться на том, что действительно важно: на проблеме, которую они пытаются решить.
Выбор хороших имен переменных
Есть еще одна цитата из «Чистого кода», которая гласит: «Вы должны называть каждую переменную с той же осторожностью, что и своему первенцу».
Хотя метафора может быть немного преувеличенной, суть остается неизменной: важно то, как вы называете вещи. Затрачивая эти дополнительные (часто небольшие) усилия заранее, чтобы выбрать описательное имя, вы помогаете своей команде (и себе в будущем) получить представление о коде. В тот момент, когда мы знаем дополнительный контекст о том, почему наш код такой, какой он есть, так что сейчас лучшее время выбрать описательное имя переменной, чтобы напомнить будущим сопровождающим об этом контексте.
Добавление комментариев
Если вы не можете уместить весь контекст внутри имени переменной, оставьте полезный комментарий вместе с любым именем, которое вы выбрали!
Возможно, вы слышали, как некоторые люди говорят, что «код должен быть самодокументированным, поэтому в комментариях нет необходимости». Хотя это правда, что мы должны стремиться сделать наш код как можно более ясным, хорошо размещенный комментарий может содержать массу дополнительного контекста, который вы действительно не сможете уместить внутри переменной.
Я большой поклонник использования комментариев для объяснения почему кода. Нам действительно не нужно комментировать, что цикл for выполняет итерацию по списку, но если он существует для решения конкретного пограничного случая, полезно знать, что это за пограничный случай. Добавление комментария может быть очень ценным, когда будущий разработчик натыкается на этот код и пытается выяснить, почему именно он находится в кодовой базе. Таким образом они узнают, безопасно ли удалить этот код.
Документация
Отличный способ измерить эмпатию вашей кодовой базы - посмотреть, что происходит, когда на борт приходит новый член команды. Сколько времени нужно, чтобы приложение запустилось локально? Какие вопросы они задают? Какие вещи они «делают неправильно» в своих первых нескольких PR?
Если какое-то время у вас нет новых членов команды, поставьте себя на место младшего разработчика, начинающего свой первый день в вашей компании. Какие вещи в вашей кодовой базе могут сбивать с толку или неясно?
Один из лучших способов бороться с неясностью - это хорошая документация. Наличие четких, хорошо написанных документов о запуске приложения или выполнении определенных задач может иметь большое значение для создания дружественной и привлекательной кодовой базы, а не непонятной и пугающей.
Однако документы также должны быть написаны с учетом эмпатии! Убедиться, что документация достаточно обширна, чтобы обеспечить ясность, но при этом не выглядеть преуменьшением, - прекрасный баланс. Один из способов, которым я пытаюсь оценить ясность моих документов, - это «оптимизировать для копирования и вставки». Предположим, что человек, читающий вашу документацию, собирается скопировать и вставить ваши примеры в свой код, потому что он пытается решить сложную проблему в сжатые сроки. Такой подход к документации заставляет вас писать примеры, которые полностью конкретизированы.
И многое другое!
Это определенно не исчерпывающий список способов сделать наш код чутким. Фактически, любой из существующих «лучших практик» можно рассматривать через призму сочувствия. Возьмите пару лучших практик, которые вам нравятся, и подумайте о том, как они положительно повлияют на будущих сопровождающих, и вы поймете, о чем я говорю!
Заключение
В конце концов, инженерия - это общение: мы говорим компьютеру, какие операции выполнять, и сообщаем нашим товарищам по команде, что должен делать код. И хотя компьютер не заботится о том, насколько чуток наш код, нашим товарищам по команде и будущим сопровождающим это важно. Сосредоточив внимание на сочувствии в коде, который мы пишем, мы создадим более качественное программное обеспечение в качестве побочного продукта.
Первоначально опубликовано на www.benjaminjohnson.me.
📝 Прочтите этот рассказ позже в Журнале.
🗞 Просыпайтесь каждое воскресное утро и слышите самые интересные истории, мнения и новости недели, ожидающие в вашем почтовом ящике: Получите примечательный информационный бюллетень›
