Основа здоровой динамики сообщества

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

Не нарушайте стандарты

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

Стандарт не идиоматичен? Были ли выбраны языки, которые вы считаете неоптимальными? Пока команда достигает своих целей, а остальная часть команды согласна со стандартами, вы должны им следовать.

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

Не нарушайте шаблоны

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

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

Не гад

Время от времени я виноват в этом, как я думаю, большинство из нас. Придирка - это небольшой комментарий при просмотре чужого кода, при проверке кода и т. Д. Обычно это строки вроде «исправить отступ здесь» или «вы начали свой { не с той строки».

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

Написать документацию

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

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

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

Написать тесты

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

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

Есть бай-ин

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

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

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

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

Почему?

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

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

Надеюсь, вам понравилась эта статья, и, пожалуйста, оставьте комментарии, если вы хотите продолжить обсуждение. Вы можете быть в курсе последних сообщений, подписавшись на меня, Джона Мюррея, на Medium и, пожалуйста, 👏, если вам понравился пост.