Я работаю фронтенд-разработчиком, и к моей команде присоединился новый коллега. Он более опытен, чем я, но у меня больше знаний о приложении, над которым мы работаем.
Итак, мы проводим проверку кода друг друга, и я знаю, что он очень любит стилизовать код и быть последовательным во всем приложении.
Теперь я просмотрел его код и сделал несколько предложений по стилю кода и соглашениям, и я всегда объяснял, почему я думаю, что это лучше.
Он ответил на мои предложения, в основном сказав, что он не согласен, и привел несколько примеров.
Затем я снова ответил на его утверждение, используя эти примеры и снова пытаясь объяснить, почему я предпочитаю именно то, что предложил.
Затем он ответил, что хотел бы отложить это обсуждение. Я предполагаю, что он до сих пор не согласен со мной и, я думаю, никогда не согласится. И я думаю, что эта дискуссия больше никогда не возникнет.
Мой вопрос в том, как я могу заставить его согласиться со мной, не заставляя его? И что мне делать, если он никогда не согласится с моими пунктами? Также мне не нравится, что он решил отложить это обсуждение. Должен ли я спросить его, когда мы обсудим это тогда?
Это происходит почти везде (так что вы не одиноки) Я дам вам совет, который даю всем:
Прекратите комментировать стилистические/косметические идеалы в ваших код-ревью.
Да, было бы неплохо, если бы кодовая база была стилистически единообразной, но реальность такова, что этого никогда не произойдет, когда над проектом работают 2 или более человек. Так может начаться, но так никогда не закончится. Вот список того, что я ищу при проверке кода, в порядке важности:
Если я пройду весь процесс проверки кода и не найду ничего, что не соответствует этим 4 вещам, тогда я могу прокомментировать стиль и очень четко указать, что это только мои предпочтения. Я делаю это, потому что считаю, что обзор кода никогда не должен содержать никаких предложений автору. Пока код имеет смысл, не комментируйте стиль, если в буквальном смысле нечего комментировать.
Но даже в этом случае это делается просто для того, чтобы показать, что вы действительно читали код и способны сделать предложение. Если коллега не хочет применять рекомендованный вами стилистический подход, оставьте его в покое (если только это не вызовет проблем с читаемостью/не сбивает с толку до точки рефакторинга).
На мой взгляд, если ваш обзор кода в основном состоит из стилей, возможно, вы недостаточно его проверяете. Я могу сосчитать по пальцам одной руки, сколько раз я мог прокомментировать только стиль.
Важным аспектом является удаление из уравнения обсуждения «он сказал, я сказал».
Вам нужно несколько вещей на месте;
Стандарты кодирования важны. В способе написания кода все еще есть место для индивидуальности, но наличие базового набора стандартов кодирования означает, что будущие разработчики могут быстро освоить кодовую базу.
У вас будет большой технический долг в существующей кодовой базе, но это сделано и работает — двигайтесь дальше, а не назад. Этот технический долг будет существовать как проект «намочить ноги» для любых будущих разработчиков, которые присоединятся к команде.
Адамкуни
анонимноSO
Натан Купер