Эмпатия в программировании

Перевод статьи «Coding with empathy».

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

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

Но как код вообще может быть эмпатичным?

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

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

Есть известная цитата из «Code For The Maintainer«, подчеркивающая этот аспект эмпатии (с небольшим вкраплением драматизма).

«Всегда пишите код так, будто человек, который будет его поддерживать, – жестокий психопат, знающий, где вы живете».

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

Как же писать эмпатичный код?

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

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

Давайте посмотрим сквозь призму эмпатии на некоторые из подходов к написанию ПО.

Автоматизированные тесты

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

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

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

Последовательность стиля

Если вы будете придерживаться в своем коде единого стиля, это очень сильно облегчит жизнь будущим мейнтейнерам. Проблемы синтаксиса и форматирования можно легко решить с помощью таких инструментов как ESLint и Prettier (это если вы пишете на JavaScript, потому что для других языков могут быть свои инструменты).

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

Выбор хороших имен для переменных

«Чистый код» дал нам еще одну цитату, ставшую популярной: «Вы должны выбирать имя для каждой переменной так, будто выбираете имя для своего первенца».

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

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

Добавление комментариев

Если вы не можете вместить весь контекст в имя переменной, оставьте рядом полезный комментарий.

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

Я большой фанат использования комментариев для объяснения всех «почему», стоящих за кодом. Нам и вправду не нужны комментарии, поясняющие, что цикл for перебирает список. Но если речь идет о специфическом edge case, будет полезно указать, что это за edge case. Добавление комментария принесет большую пользу в будущем, когда какой-нибудь разработчик станет разбирать ваш код, пытаясь понять, какую роль он играет в кодовой базе. Это очень поможет ему определить, безопасно ли будет удалить этот код.

Документация

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

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

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

Но доки тоже нужно писать с учетом эмпатии! Старайтесь, чтобы документация была достаточно обширна, проясняла все нужные моменты и при этом не унижала читателя.

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

И многое другое!

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

Заключение

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]