Согласование правил бойскаутов и оппортунистического рефакторинга с обзорами кода

Я большой сторонник правила бойскаутов :

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

Я также большой сторонник связанной идеи Оппортунистического Рефакторинга :

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

Особо обратите внимание на следующую выдержку из статьи о рефакторинге:

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

Там, где я работаю, есть одна практика разработки, которая вызывает серьезные трения - Code Review (CR). Всякий раз, когда я изменяю что-либо, что не входит в сферу моего «назначения», мои рецензенты упрекают меня в том, что я усложняю изменение для обзора. Это особенно актуально, когда речь идет о рефакторинге, поскольку это затрудняет сравнение различий между строками. Этот подход является стандартным здесь, что означает, что оппортунистический рефакторинг проводится редко, и имеет место только «запланированный» рефакторинг (который обычно слишком мал, слишком поздно), если он вообще выполняется.

Я утверждаю, что преимущества того стоят, и что 3 рецензента будут работать немного усерднее (чтобы на самом деле понять код до и после, а не смотреть на узкую область видоизмененности строк - сам обзор был бы лучше благодаря одному этому ) так что следующие 100 разработчиков, читающих и поддерживающих код, получат пользу. Когда я представляю этот аргумент моим рецензентам, они говорят, что у них нет проблем с моим рефакторингом, если он не в том же CR. Однако я утверждаю, что это миф:

(1) В большинстве случаев вы понимаете, что и как вы хотите провести рефакторинг, когда находитесь в середине своего задания. Как говорит Мартин Фаулер:

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

(2) Никто не будет благосклонно смотреть на то, как вы выпускаете «рефакторинг» КР, которые вы не должны были делать. У CR есть определенные накладные расходы, и ваш менеджер не хочет, чтобы вы «тратили свое время» на рефакторинг. Когда это связано с изменением, которое вы должны сделать, эта проблема сводится к минимуму.

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

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

Любые мысли о том, как я могу исправить эту ситуацию?

Итак, теперь здесь больше вещей, чем подходит для комментариев.

ТЛ; др

Ваша интуиция о том, что вы должны делать (рефакторинг по ходу дела), верна.

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

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

Проблемы рабочего процесса / офисной политики

По сути, я бы дал ту же рекомендацию, что и GlenH7, чтобы вы создали два коммита - один только с рефакторингом и (явно или явно) без функциональных изменений, а другой с рассматриваемыми функциональными изменениями.

Тем не менее, может быть полезно, если вы находите много ошибок, выбрать одну категорию ошибок, которую нужно исправить в одном CR. Затем у вас есть один коммит с комментарием типа «дедупликация кода», «исправление ошибок типа X» или что-то еще. Поскольку это вносит один тип изменений, предположительно в нескольких местах, его следует рассмотреть тривиально . Это означает, что вы не можете исправить каждую найденную ошибку, но может сделать менее трудным прохождение через нее.

Проблемы с VCS

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

1. если вы используете git, у вас есть отличные инструменты для этого

   • Вы можете использовать git add -iдля интерактивной постановки из командной строки
   • Вы можете использовать git guiи выбирать отдельные фрагменты и строки для стадии (это один из немногих инструментов графического интерфейса, связанных с VCS, который я предпочитаю командной строке, а другой - хороший редактор трехстороннего слияния)
   • Вы можете сделать множество мелких коммитов (отдельные изменения или исправить один и тот же класс ошибок в нескольких местах), а затем изменить их порядок, объединить или разделить их с помощью rebase -i

2. если вы не используете git, ваша VCS может иметь инструменты для такого рода вещей, но я не могу посоветовать, не зная, какую систему вы используете

   Вы упомянули, что используете TFS - я считаю, что он совместим с git начиная с TFS2013. Возможно, стоит поэкспериментировать с использованием локального клона git репозитория для работы. Если это отключено или у вас не работает, вы все равно можете импортировать исходный код в локальное репозиторий git, работать там и использовать его для экспортировать ваши последние коммиты.

3. Вы можете сделать это вручную в любой VCS, если у вас есть доступ к основным инструментам, таким как diffи patch. Это более болезненно, но, безусловно, возможно. Основной рабочий процесс будет:

   1. внесите все изменения, протестируйте и т. д.
   2. использовать diffдля создания (контекстного или унифицированного) файла патча со всеми изменениями с момента последнего коммита
   3. разделите это на два файла: в итоге вы получите один файл патча, содержащий рефакторинги, и один с функциональными изменениями
      • это не совсем тривиально - инструменты, такие как режим Emacs Diff, могут помочь
   4. поддержать все
   5. вернуться к последнему коммиту, использовать patchдля воспроизведения одного из файлов патчей, зафиксировать эти изменения
      • NB. если патч не был применен корректно, возможно, вам придется исправить неисправные блоки вручную
   6. повторите 5 для второго файла патча

Теперь у вас есть две фиксации, с вашими изменениями, разделенными соответствующим образом.

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

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

Любые мысли о том, как я могу исправить эту ситуацию?

Продолжать делать то, что ты делаешь?

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

Что может помочь, так это быть менее воинственным. Обзоры кода не должны быть воинственными «Зачем ты это сделал?», Они должны быть совместными «Эй, ребята, пока я был здесь, я все исправил!». Работать (с вашим лидером / менеджером, если возможно) над изменением этой культуры сложно, но очень важно создать высокофункциональную команду разработчиков.

Вы также можете работать (с вашим руководителем / менеджером, если это возможно), чтобы продвигать важность этих идей с вашими коллегами. Сделайте так, чтобы вы спросили: «Почему вы, ребята, не заботитесь о качестве?» вместо того, чтобы спросить: «Почему вы всегда делаете эти бесполезные вещи?».

У меня есть много сочувствия к вашей ситуации, но мало конкретных предложений. Если ничего другого, может быть, я убедлю вас, что, как бы ни была плоха ситуация, могло быть и хуже. ВСЕГДА может быть хуже. :-)

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

Код Отзывы

Я был в группе, которая ненавидела обзоры кода. Группа была сформирована путем слияния двух групп из отдельных частей компании. Я пришел из группы, которая несколько лет занималась проверкой кода, и в целом с хорошими результатами. Большинство из нас полагало, что обзоры кода были хорошим использованием нашего времени. Мы объединились в большую группу, и, насколько мы могли судить, эта «другая» группа даже не слышала о проверках кода. Теперь мы все работали над «своей» базой кода.

Когда мы слились, все было плохо. Новые функции были на 6-12 месяцев позже, год за годом. Журнал ожидания был огромным, растущим и истощающим жизнь. Кодекс владения был Сильный, особенно среди самых старших "гуру". «Художественные ветки» иногда длились годами и охватывали несколько релизов; иногда НИКТО, но один разработчик видел код до того, как он попал в основную ветку. На самом деле «функциональная ветвь» вводит в заблуждение, поскольку предполагает, что код был где-то в хранилище. Чаще всего это было только на индивидуальной системе разработчика.

Руководство согласилось с тем, что нам нужно «что-то сделать», прежде чем качество станет неприемлемо низким. :-) Их ответ был Code Reviews. Code Reviews стал официальным пунктом «Ты будешь», который предшествовал каждой регистрации. Инструмент, который мы использовали, был Review Board.

Как это работает в культуре, которую я описал? Лучше, чем ничего, но это было больно, и потребовалось больше года, чтобы достичь своего рода минимального уровня соответствия. Некоторые вещи, которые мы наблюдали:

1. Инструмент, который вы используете, имеет тенденцию фокусировать обзоры кода определенным образом. Это может быть проблемой. Совет по рассмотрению предоставляет вам красивые, красочные построчные различия и позволяет добавлять комментарии к строке. Это заставляет большинство разработчиков игнорировать все строки, которые не изменились. Это хорошо для небольших, изолированных изменений. Это не очень хорошо для больших изменений, больших кусков нового кода или кода, который имеет 500 экземпляров переименованной функции, смешанной с 10 строками новой функциональности.
2. Даже при том, что мы были в старой, больной кодовой базе, которая в основном никогда не проверялась раньше, рецензенту стало «невежливо» комментировать все, что НЕ было строкой изменений, даже указывать на очевидную ошибку. «Не беспокойте меня, это важная регистрация, и у меня нет времени, чтобы исправить ошибки».
3. Магазин для "простого" рецензента. Некоторые люди просматривают 10-файловый обзор с 2000 измененными строками в течение 3 минут и нажимают кнопку «Отправь!». Все быстро узнают, кто эти люди. Если вы действительно не хотите, чтобы ваш код был проверен в первую очередь, отправьте его «простому» рецензенту. Ваша регистрация не будет замедлена. Вы можете вернуть услугу, став «легким» рецензентом своего кода.
4. Если вы ненавидите обзоры кода, просто игнорируйте электронные письма, которые вы получаете от Review Board. Не обращайте внимания на последующие действия от членов вашей команды. Неделями. Пока у вас не будет 3 дюжины открытых отзывов в очереди, и ваше имя будет появляться на групповых собраниях несколько раз. Тогда станьте «легким» рецензентом и очистите все ваши отзывы до обеда.
5. Старайтесь не посылать свой код «жесткому» рецензенту. (Разработчик, который будет задавать или отвечать на вопросы, подобные этому.) Все быстро узнают, кто такие «жесткие» рецензенты, так же, как они изучают простых. Если проверки кода - это растрата времени (™), то чтение подробного отзыва о СВОЕМ коде - это и растрата времени (™), и оскорбление.
6. Когда проверки кода являются болезненными, люди откладывают их и продолжают писать больше кода. Вы получаете меньше обзоров кода, но каждый из них БОЛЬШОЙ. Вам нужно больше меньших обзоров кода, а это значит, что команде нужно выяснить, как сделать их как можно более безболезненными.

Я думал, что собираюсь написать несколько параграфов о Code Reviews, но оказывается, что я в основном писал о культуре. Я думаю, это сводится к следующему: проверки кода могут быть полезны для проекта, но команда получает только те преимущества, которые заслуживает.

Рефакторинг

Моя группа презирала рефакторинг даже больше, чем ненавидела обзоры кода? Конечно! По всем очевидным причинам, которые уже были упомянуты. Вы тратите мое время на проверку кода, и даже не добавляете функцию и не исправляете ошибку!

Но код по-прежнему остро нуждался в рефакторинге. Как продолжить?

1. Никогда не смешивайте изменение рефакторинга с функциональным изменением. Ряд людей упомянули об этом. Если проверки кода - это проблема, не увеличивайте ее. Это больше работы, но вы должны запланировать отдельный обзор и отдельную регистрацию.
2. Начните с малого. Очень маленький. Даже меньше, чем это. Используйте очень маленькие рефакторинги, чтобы постепенно научить людей, что рефакторинг и обзоры кода не являются чистым злом. Если вы можете прокрасться одним крошечным рефакторингом в неделю без особой боли, через пару месяцев вы сможете сойти с рук с двумя в неделю. И они могут быть немного больше. Лучше чем ничего.
3. У нас практически не было модульных тестов. Так что рефакторинг запрещен, верно? Не обязательно. Для некоторых изменений компилятор является вашим модульным тестом. Сосредоточьтесь на рефакторингах, которые вы можете проверить. Избегайте изменений, если они не могут быть проверены. Возможно, вместо этого потратьте время на написание юнит-тестов.
4. Некоторые разработчики боятся рефакторинга, потому что боятся ВСЕХ изменений кода. Мне потребовалось много времени, чтобы распознать этот тип. Напишите кусок кода, возитесь с ним, пока он не «заработает», и НИКОГДА не хотите его менять. Они не обязательно понимают, ПОЧЕМУ это работает. Изменения рискованны. Они не доверяют себе вносить ЛЮБЫЕ изменения и, конечно же, не будут доверять вам. Предполагается, что рефакторинг - это небольшие, безопасные изменения, которые не меняют поведение. Есть разработчики, для которых сама идея «изменений, которые не меняют поведение» немыслима . Я не знаю, что предложить в этих случаях. Я думаю, что вы должны пытаться работать в областях, которые им не нужны. Я был удивлен, когда узнал, что этот тип может иметь долго,

Почему бы вам не сделать оба, но с отдельными коммитами?

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

Но если вы видите ряд вопиющих проблем, есть два варианта, которым вы можете следовать.

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

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

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

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

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

Кроме того, предполагая, что вы выполняете TDD или какой-либо другой красно-зеленый рефакторинг, один из способов обеспечить взаимодействие со сверстниками - это использовать метод сопряжения в пинг-понге. Проще говоря, что драйвер вращается для каждого шага цикла RGR, то есть пара 1 записывает неудачный тест, пара 2 исправляет его, пара 1 выполняет рефакторинг, пара 2 пишет неудачный тест .... и так далее.

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

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

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

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

1. Не проводите рефакторинг, если вы не можете проверить изменения, внесенные с помощью автоматических тестов.

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

Перед рефакторингом убедитесь, что есть юнит-тесты. Если нет юнит-тестов, напишите несколько! Тогда рефакторинг прочь, и у ваших рецензентов кода не будет (законных) оправданий расстроиться.

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

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

Вместо того, чтобы переименовывать идиоматические переменные, просто поместите комментарии, объясняющие, что они есть. Если они не идиоматичны, пожалуйста, переименуйте их. Не оставляйте i, j, k, x, yи т.д. плавающие вокруг , когда лучшие имена будут работать.

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

У нас есть следующие понятия, которые мы всегда сокращаем, когда говорим о них: «Зона концерна» становится «AOC», «Взрыв парового облака» становится VCE, и тому подобное. В нашей кодовой базе кто-то реорганизовал все экземпляры, называемые aoc, в AreaOfConcern, VCE вaporCloudExplosion, nPlanes в confiningPlanesCount ... что на самом деле затруднило чтение кода для людей, обладающих знаниями в конкретной области. Я тоже был виновен в подобных вещах.

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

Теперь у этого вопроса есть две разные проблемы: простота рассмотрения изменений в обзорах кода и время, потраченное на рефакторинг.

Там, где я работаю, есть одна практика разработки, которая вызывает серьезные трения - Code Review (CR). Всякий раз, когда я изменяю что-либо, что не входит в сферу моего «назначения», мои рецензенты упрекают меня в том, что я усложняю изменение для обзора.

Как уже говорилось в других ответах - можете ли вы отделить проверки рефакторинга от изменений кода (не обязательно в качестве отдельных обзоров)? В зависимости от того, какой инструмент вы используете для проверки кода, вы сможете просматривать различия только между конкретными ревизиями (Atlassian's Crucible определенно делает это).

(2) Никто не будет благосклонно смотреть на то, как вы выпускаете «рефакторинг» КР, которые вы не должны были делать. CR имеет определенные накладные расходы, и ваш менеджер не хочет, чтобы вы «тратили время» на рефакторинг. Когда это связано с изменением, которое вы должны сделать, эта проблема сводится к минимуму.

Если рефакторинг является простым и облегчает понимание кода (и это все, что вам следует делать, если это просто рефакторинг), тогда обзор кода не должен занимать много времени и должен быть минимальными накладными расходами, которые выигрывают, когда кто-то должен прийти и посмотреть код снова в будущем. Если ваши боссы не могут это сделать, вам, возможно, придется осторожно подтолкнуть их к некоторым ресурсам, в которых обсуждается, почему правило бойскаута ведет к более продуктивным отношениям с вашим кодом. Если вы сможете убедить их в том, что «трата [вашего] времени» теперь сэкономит в два, пять или десять раз больше, когда вы / кто-либо еще вернетесь для выполнения дополнительной работы над этим кодом, тогда ваша проблема должна исчезнуть.

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

Вы пытались довести эти проблемы до сведения своих коллег и обсудить, почему их стоит исправить? И можно ли исправить какие-либо из них автоматически (при условии, что у вас достаточно тестового покрытия, чтобы подтвердить, что вы не разбили материал с помощью автоматического рефакторинга)? Иногда не стоит тратить свое время на рефакторинг, если это действительно придирчивый материал. Вся ваша команда использует ReSharper? Если да, есть ли у вас общая политика относительно того, какие предупреждения / правила применяются? Если это не так, возможно, вам следует продемонстрировать, где инструмент помогает вам определить области кода, которые являются возможными источниками будущей боли.

Я помню, как лет 25 назад «чистил» код, над которым я работал, для других целей, в основном путем переформатирования блоков комментариев и выравнивания вкладок / столбцов, чтобы сделать код аккуратным и, следовательно, более простым для понимания (никаких реальных функциональных изменений). , Мне нравится код, который аккуратен и упорядочен. Ну, старшие разработчики были в ярости. Оказывается, они использовали какое-то сравнение файлов (diff), чтобы увидеть, что изменилось, по сравнению с их личными копиями файла, и теперь он давал всевозможные ложные срабатывания. Я должен отметить, что наша библиотека кода была на мэйнфрейме и не имела контроля версий - вы в основном переписали все, что там было, и это было все.

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

Если вы можете разделить запрошенное изменение и незапрошенный рефакторинг на (множество) отдельных коммитов, как отметили @Useless, @Telastyn и другие, то это лучшее, что вы можете сделать. Вы по-прежнему будете работать над одним CR, без административных накладных расходов на создание «рефакторинга». Просто держите ваши коммиты маленькими и сфокусированными.

Вместо того, чтобы дать вам несколько советов, как это сделать, я предпочитаю указать вам гораздо большее объяснение (фактически, книгу) от специалиста. Таким образом, вы сможете узнать намного больше. Прочитайте Работая эффективно с Устаревшим Кодексом (Майклом Фезерсом) . Эта книга может научить вас, как сделать рефакторинг, чередующийся с функциональными изменениями.

Темы включают в себя:

• Понимание механизма изменения программного обеспечения: добавление функций, исправление ошибок, улучшение дизайна, оптимизация производительности
• Получение унаследованного кода в тестовом жгуте
• Написание тестов, которые защитят вас от новых проблем
• Методы, которые можно использовать с любым языком или платформой - с примерами на Java, C ++, C и C #
• Точная идентификация того, где необходимо внести изменения в код
• Справиться с устаревшими системами, которые не являются объектно-ориентированными
• Обработка приложений, которые не имеют какой-либо структуры

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

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

Это человеческая природа. Мы привыкли иметь дело с реальными проблемами, а не пытаться их предотвратить. Мы реактивные, а не активные.

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

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

Если честно, ваш менеджер не всегда убежден, что ваше лекарство на самом деле так здорово, как вы думаете. (Змеиное масло?) Там есть умение продавать. Ваша работа - помочь ему увидеть выгоду.

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

Если вы можете разделить запрошенное изменение и незапрошенный рефакторинг на два отдельных запроса на изменение, как отмечает @ GlenH7, то это лучшее, что вы можете сделать. Тогда вы не «парень, который тратит время», а «парень, который работает вдвое больше».

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

Если ваша компания не хочет «тратить время на рефакторинг» (плохой знак с их стороны), то они должны предоставить вам файл «подавления предупреждений» (каждый инструмент имеет свой собственный механизм), чтобы вы больше не раздражались такие предупреждения. Я говорю это для того, чтобы предоставить вам варианты для различных сценариев, даже в худшем случае. Также лучше иметь четко сформулированные соглашения между вами и вашей компанией, а также об ожидаемом качестве кода, а не неявные предположения с каждой стороны.