Должен ли я настаивать на том, чтобы мы выполняли проверку кода перед слиянием с транком?

Запрошенная повторная публикация из StackOverflow:

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

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

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

Должен ли я настаивать на том, чтобы мы выполняли проверку кода перед слиянием с транком или я просто сука качества кода?

Я был в подобных ситуациях и раньше, и imho, это зависит от "я должен поддерживать код".

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

Читая это:

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

Я думаю, что ваша проблема больше, чем просто обзоры кода. Кажется, вам не хватает нескольких рекомендаций и / или они не реализованы. Не иметь / несколько юнит-тестов может быть плохой идеей, но зависит от конкретного случая. Тем не менее, breaking encapsulation, writing huge classes, ...действительно создайте подверженный ошибкам код, так что он обязательно должен быть исправлен.

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

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

То, что я пытаюсь сказать, - ты должен выбрать свои сражения. Можно проиграть битву за какой-то незначительный служебный класс, чтобы выиграть войну доставки (или, по сути, эту действительно ДЕЙСТВИТЕЛЬНУЮ войну подсистем).

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

Старшие разработчики могут иметь привилегию не проверенных проверок, когда они станут достаточно добросовестными, чтобы запросить проверку в случае необходимости.

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

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