Это означает именно то, что он говорит.

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

Что именно я имею в виду, когда говорю программирование с эмпатией? Эмпатия, в английском лексиконе, это просто обычное слово. Я не имею в виду какую-то библиотеку Python, фреймворк React или какую-то новую криптовалюту (кто-то должен был это сказать). Это просто термин, который означает именно то, что он говорит. Но для технических деталей я приведу определение. Согласно Оксфордскому словарю для учащихся, эмпатия определяется «способностью понимать чувства, опыт и т. д. другого человека.» Довольно просто, не так ли? Однако какое это имеет отношение к кодированию?

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

Целью этой статьи является работа с соединениями, но даже если вы пишете программу для себя, основные принципы остаются прежними.

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

Что делает хороший код отличным?

Что представляет собой хороший код? Это не мозговой штурм. Хороший кусок кода работает, как и ожидалось, да! Это также эффективно, что означает более быстрый отклик и небольшой объем памяти. Желательно иметь переносимость и масштабируемость. И, возможно, он модульный и точный; в конце концов, кто не оценит короткий и приятный трехстрочный код, который кажется слишком сложным, но делает именно то, что делал бы его десятистрочный аналог? Все это характеристики хорошего кода.

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

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

«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям». — Мартин Фаулер

Но так ли это важно?

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

Откуда я все это знаю?

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

Где можно научиться писать отличный код?

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

Хорошо, все было сделано из лучших побуждений, но хороший код требует времени!

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

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

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

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

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