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

Разработчики до этой статьи:

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

1. Определение границ задачи (пытаемся понять, а что вообще нужно?)
2. Обдумывание решения (решаем, как будем добиваться посталенной цели)
3. Написание кода (тут все ясно)
4. Отладка (если потребуется - возвращаемся на шаг 3)
5. Фиксация результата (тут может быть залитие в ветку, прохождение ревью, запуск тестов и т.д.)

Шаги 1, 2 и 4 очень субъективны и туманны, каждый это делает как ему удобно. Если я обдумываю решение, исходя из требуемого результата или исходя из имеющихся наработок - это мое дело, на ком-то другом это не скажется. С опытом каждый выводит для себя удобные методы поиска решения, обдумывания задачи и отладки кода.
Фиксация результата может сильно отличаться в зависимости от специфики задач, команды и некоторых других вещей. При определённых обстоятельствах фиксации может и вовсе не быть. Обычно это как-то зарегламентировано или просто держится в уме.

Может показаться, что написание кода ¬– полностью личное дело каждого разработчика: как хочу, так и пишу (а если что-то будет не так, я узнаю об этом на 5 шаге). Если подумать, то мы хотим получить качественное решение за кратчайшие сроки, а в случае, если мы будем писать код "не так" как остальные - споров и драк на этапе ревью (если имеется команда) не избежать. А это уже повлечет за собой совершенно ненужные траты драгоценного времени и не менее драгоценных нервов.
Тут возникает закономерный вопрос: "Если я работаю один - мне это не нужно?". Вынужден сообщить - это заблуждение. В будущем будет тяжело разобраться в том, что ты писал ранее, не будет какого-то стандарта, код будет постоянно засоряться, а доработки будут выливаться в большую проблему. Твой код будет выглядеть буквально так:

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

Кто-то утверждает, что это идеал:

if(count == 1)
  return;

другой скажет, что вот идеал:

if(count == 1) return;

а мне вообще нравится вот так:

if(count == 1)
{
  return;
}

"Как же быть?", спросите вы. Вот мы и выявили первую проблему.

Code Style #

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

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

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

Попробуем выдвинуть некие требования для такого инструмента. Мы от него будем ждать:

• Кроссплатформенность
• Работа независимо от IDE
• Возможность встраивания в CI/CD
• Настраиваемые правила

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

Не со всеми бедами может справиться форматтер, например, в случае если класс содержит Disposable объекты, нам нужно их уничтожить (реализовав в классе интерфейс IDisposable). Тут в дело должен вступить Анализ кода.

Анализ кода #

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

По ссылке выше можно посмотреть и настроить собственные правила для проекта. У нас эти правила утверждены на уровне компании и все команды придерживаются их (в случае если команде что-то не нравится, она сама может вносить изменения в спорные правила). Что нам это даст:

• При переходе в другую команду стиль кода остается прежним
• Чтение и ревью легче
• Ошибку допустить сложнее

Анализ кода также можно запускать и на этапе CI/CD, например, используя SonarQube. В совокупности все это дает кучу приятных бонусов, в код труднее посадить баг, все контроллируется и настраивается.

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

• Пишем код
• Форматируем код
• Анализируем код
• Отправляем на ревью

Возникает вопрос - это же только усложнит работу и заставит нас тратить больше времени, пока мы отформатируем, пока отправим, пока CI/CD отработает, пока мы увидим результаты, опять поправим и так по кругу? А вдруг мы забудем про что-то? Нас опять будут бить на ревью? Код будет дурно пахнуть?

Чтобы не ходить по всем кругам ада, мы можем запускать все это автоматически и локально, с этим нам помогут git-хуки.

Git-хуки #

У нас есть прекрасная возможность запуска собственных скриптов в случае определенных событий git-а. Например, перед созданием коммита мы можем отформатировать код, проанализировать его и в случае ошибки - отменить создание коммита с требованием исправления всех ошибок. Про git-хуки можно почитать тут.

Чтобы не городить огород и не писать самописные решения - за нас все придумали. Есть прекрасный инстурмент Husky.Net, который позволяет легко создавать и настраивать хуки в .net проектах. Нам останется написать конфигурацию для запуска анализа и форматированния при попытке создания коммита - и все! Наш код форматируется автоматически, не содержит ошибок и приятно пахнет!

Рассмотрим пример конфигурации Husky.Net, который запускает форматированние всех измененных файлов, а также проверяет код на Warning-и:

{
  "tasks": [
    {
      "name": "Run csharpier",
      "command": "dotnet",
      "args": [ "csharpier", "${staged}" ],
      "include": [ "**/*.cs" ]
    },
    {
      "name": "warning-check",
      "command": "dotnet",
      "group": "pre-commit",
      "args": [ "build", "/warnaserror", "--no-incremental", "--no-restore" ],
      "include": [ "**/*.cs" ]
    }
  ]
}

Данная конфигурация заставит считать любой warning ошибкой, но в ито же время наш код будет прекрасен!

Выводы #

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

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

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

🙏🙏🙏

Поскольку ты зашел так далеко, я буду очень признателен, если ты поделишься этой статьей в своей любимой социальной сети 💖! Для обратной связи, пожалуйста, напиши в Telegram.

Опубликовано 10.01.2024