Узгодження правила скаута хлопчика та опортуністичного рефакторингу з оглядами коду

Я великий віруючий у правило скаутського хлопчика :

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

Я також дуже вірую у споріднену ідею опортуністичного рефакторингу :

Хоча є місця для певних запланованих зусиль по рефакторингу, я вважаю за краще заохочувати рефакторинг як опортуністичну діяльність, що робиться коли і де потрібно, коли код очищається - ким завгодно. Це означає, що в будь-який момент хтось бачить якийсь код, який не так зрозумілий, як це має бути, він повинен скористатися можливістю виправити його тут же, а потім - або принаймні протягом декількох хвилин

Зокрема, зверніть увагу на такий уривок із статті про рефакторинг:

Я з обережністю ставляться до будь-яких практик розвитку, які спричиняють тертя для опортуністичного рефакторингу ... Я відчуваю, що більшість команд недостатньо рефакторингують, тому важливо звертати увагу на все, що заважає людям робити це. Щоб уникнути цього, будьте в курсі будь-якого часу, коли ви відчуєте, що не бажаєте робити невеликий рефакторинг, той, на який ви впевнені, займе лише хвилину-дві. Будь-який такий бар’єр - це запах, який повинен спонукати до розмови. Тож зробіть зауваження щодо розгубленості та піднесіть це команді. Принаймні, це слід обговорити під час наступної ретроспективи.

Там, де я працюю, є одна практика розробки, яка викликає сильне тертя - Code Review (CR). Щоразу, коли я змінюю що-небудь, що не входить до мого "доручення", мене рецензенти докоряють, що я ускладнюю перегляд змін. Особливо це стосується рефакторингу, оскільки це робить "порівняння за рядком" різним порівнянням. Цей підхід є стандартом тут, що означає умовно-патологічний рефакторинг рідко робиться, і лише "плановий" рефакторинг (як правило, занадто мало, занадто пізно) має місце, якщо він взагалі є.

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

(1) У більшості випадків ви усвідомлюєте, що і як ви хочете зробити рефактор, коли ви знаходитесь в середині вашого завдання. Як стверджує Мартін Фаулер:

Коли ви додаєте функціональність, ви розумієте, що якийсь доданий вами код містить деяке дублювання з деяким наявним кодом, тому вам потрібно перефактурувати існуючий код, щоб очистити речі. краще, якщо взаємодія з існуючими класами було змінено. Скористайтеся можливістю зробити це, перш ніж вважати себе зробленим.

(2) Ніхто не збирається прихильно дивитись на те, щоб випустити "рефакторинг" CR, які ви не мали робити. У 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 repo, працювати там і використовувати його для експортуйте остаточні зобов'язання.

3. ви можете це зробити вручну в будь-якому СКС, якщо у вас є доступ до основних інструментів, таких як diffі patch. Це болючіше, але, безумовно, можливо. Основним робочим процесом буде:

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

Тепер у вас є два коміти, при цьому ваші зміни будуть належним чином розподілені.

Зауважте, що, ймовірно, є інструменти для полегшення управління патчем - я просто не використовую їх, оскільки git робить це для мене.

Я вважаю, що запити на зміну великі та формальні для вашої компанії. Якщо ні, просто внесіть зміни (де це можливо) у багато невеликих комітетів (як і належить).

Будь-які думки про те, як я можу виправити цю ситуацію?

Продовжувати робити те, що ти робиш?

Я маю на увазі, всі ваші думки і виводи цілком коректні. Ви повинні виправити те, що бачите. Люди не роблять запланованого рефакторингу достатньо. І ця користь для всієї групи важливіша, ніж незручність у кількох.

Що може допомогти - бути менш бойовим. Огляди коду не повинні бути бойовими: "Чому ти це зробив?", Вони повинні бути спільними "Ей, хлопці, поки я був тут, я все це виправив!". Працювати (якщо можливо, з вашим керівником / менеджером), щоб змінити культуру - це важко, але досить важливо, щоб створити високу функціонуючу команду розвитку.

Ви також можете попрацювати (якщо можливо, зі своїм керівником / менеджером), щоб сприяти важливості цих ідей разом із колегами. Попросіть вас запитати "чому ви не дбаєте про якість?" замість них запитують "чому ти завжди робиш ці марні речі?".

Я дуже симпатизую вашій ситуації, але мало конкретних пропозицій. Якщо нічого іншого, можливо, я переконаю вас, що як би погана ситуація, це може бути і гірше. ЗАВЖДИ може бути гірше. :-)

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

Огляди коду

Я був у групі, яка перевіряє HATED код. Група утворилася шляхом об'єднання двох груп з окремих частин компанії. Я прийшов із групи, яка кілька років займалась переглядом коду, із загалом хорошими результатами. Більшість із нас вважали, що огляди коду добре використовують наш час. Ми об'єдналися в більшу групу, і якнайближче ми могли сказати, що "інша" група ніколи навіть не чула про перегляд коду. Зараз ми всі працювали над "їхньою" кодовою базою.

Все не було добре, коли ми злилися. Нові можливості були запізнені на 6-12 місяців, рік за роком. Відставання помилок було величезним, зростаючим та життєздатним. Володіння кодом було сильним, особливо серед найстарших "гуру". "Функціональні гілки" інколи тривали роки і охоплювали кілька випусків; іноді NOBODY, але окремий розробник бачив код, перш ніж він потрапив у головну гілку. Насправді "функціональна галузь" вводить в оману, оскільки передбачає, що код був десь у сховищі. Частіше це було лише в індивідуальній системі розробника.

Керівництво погодилося, що нам потрібно "щось зробити", перш ніж якість стане неприпустимо низькою. :-) Їхньою відповіддю було Code Reviews. Code Reviews став офіційним пунктом "Ти повинен", щоб передувати кожному заїзду. Інструментом, яким ми користувались, була Оглядова рада.

Як це діяло в описаній мною культурі? Краще, ніж нічого, але це було боляче і пішло більше року, щоб досягти свого роду мінімального рівня відповідності. Деякі речі, які ми спостерігали:

1. Використовуваний інструмент певним чином фокусує огляди коду. Це може бути проблемою. Рада з огляду дає вам приємні, барвисті різко-рядкові розбіжності та дозволяє додавати коментарі до рядка. Це змушує більшість розробників ігнорувати всі рядки, які не змінилися. Це добре для невеликих, поодиноких змін. Це не так добре для великих змін, великих запитів нового коду чи коду, який містить 500 екземплярів перейменованої функції, змішаної з 10 рядками нового функціоналу.
2. Незважаючи на те, що ми опинилися в старій, хворій кодовій базі, яка раніше ніколи не переглядалася, рецензент став "нечесним", щоб коментувати все, що НЕ було лінією змін, навіть щоб вказати на очевидну помилку. "Не турбуйте мене, це важлива реєстрація, і я не встигаю виправляти помилки."
3. Купуйте "легкого" рецензента. Деякі люди подивляться 10-файловий огляд з 2000 зміненими рядками протягом 3 хвилин і натисніть "Доставка!". Всі швидко дізнаються, хто такі люди. Якщо ви дійсно не хочете, щоб ваш код переглядався в першу чергу, надішліть його "легкому" рецензенту. Ви не затримаєте реєстрацію реєстрації. Ви можете повернути послугу, ставши «легким» рецензентом свого коду.
4. Якщо ви ненавидите огляди коду, просто ігноруйте електронні листи, отримані від Board Board. Ігноруйте подальші дії членів вашої команди. Тижнями. Поки у вашій черзі не з’явиться 3 десятки відкритих відгуків, і ваше ім’я кілька разів з’явиться на групових зборах. Потім станьте "легким" рецензентом і очистіть усі свої відгуки до обіду.
5. Уникайте надсилання коду "важкому" рецензенту. (Такий розробник, який би задав або відповів на таке питання, як це.) Кожен швидко дізнається, хто такі "важкі" рецензенти, як і вони дізнаються прості. Якщо огляди коду - це Waste Of Time (™), то читання детальних відгуків про код, який ви ВЛАСНИЙ - це і Waste Of Time (™), і образа.
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 до vaporCloudExplosion, nPlanes до confiningPlanesCount ..., що зробило код фактично набагато складнішим для читання людям, які мали певні знання в галузі. Я теж винен, що робив подібні речі.

Це взагалі може не застосовуватися у вашій ситуації, але є мої думки з цього приводу.

Зараз у цього питання є дві чіткі проблеми - простота перегляду змін у оглядах коду та час, витрачений на рефакторинг.

Де я працюю, є одна практика розробки, яка викликає сильне тертя - Code Review (CR). Щоразу, коли я змінюю що-небудь, що не входить до мого "доручення", мене рецензенти докоряють, що я ускладнюю перегляд змін.

Як сказано в інших відповідях - чи можна відокремити контрольно-провідникові документи від зміни коду (не обов'язково як окремі відгуки)? Залежно від інструменту, який ви використовуєте для перевірки коду, ви повинні мати можливість переглядати відмінності лише між певними редакціями (напевне, це робиться в Crucible Atlassian).

(2) Ніхто не збирається прихильно дивитись на те, щоб випустити "рефакторинг" CR, які ви не мали робити. У CR є певні накладні витрати, і ваш менеджер не хоче, щоб ви "витрачали свій час" на рефакторинг. Якщо це пов'язано зі змінами, які ви повинні зробити, ця проблема зводиться до мінімуму.

Якщо рефакторинг є простим і полегшує розуміння коду (що все, що вам слід зробити, якщо це просто рефакторинг), огляд коду не повинен забирати багато часу і повинен бути мінімальним накладними витратами, які виграють у лопат, коли хтось має прийти і знову переглянути код. Якщо ваші начальники не в змозі це зробити, то, можливо, вам потрібно буде обережно підвести їх до деяких ресурсів, які обговорюють, чому правило хлопців-скаутів призводить до більш продуктивних стосунків з вашим кодом. Якщо ви зможете переконати їх у тому, що "витрата [вашого] часу" тепер зекономить у два, п'ять чи десять разів набагато пізніше, коли ви / хтось інший повернеться, щоб зробити більше роботи над цим кодом, тоді ваша проблема повинна піти назовні.

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

Ви намагалися довести ці питання до відома своїх колег та обговорити, чому їх варто виправити? І чи можна будь-яку з них виправити автоматично (за умови, що у вас достатньо тестового покриття, щоб підтвердити, що ви не зламали речі за допомогою автоматичного рефакторингу)? Іноді не варто «витрачати свій час» на проведення рефакторингу, якщо це дійсно прискіпливі речі. Чи використовує ваша команда ReSharper? Якщо вони є, чи є у вас спільна політика щодо того, які застереження / правила виконуються? Якщо цього немає, знову, можливо, вам слід продемонструвати, де інструмент допомагає вам визначити області коду, які є можливими джерелами майбутнього болю.

Я пам’ятаю 25 років або більше тому «очищення» коду, над яким я працював для інших цілей, головним чином шляхом переформатування блоків коментарів та вирівнювання вкладок / стовпців, щоб зробити код чітким і, отже, простішим для розуміння (відсутність фактичних функціональних змін) . Мені здається, мені подобається чіткий і впорядкований код. Що ж, старші розробники були розлючені. Виявляється, вони використовували якесь порівняння файлів (diff), щоб побачити, що змінилося, порівняно з їх особистими копіями файлу, і тепер він давав всілякі помилкові позитиви. Я мушу зазначити, що наша бібліотека кодів була на мейнфреймі і не мала контролю версій - ви в основному переробили все, що там було, і це було все.

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

Якщо ви можете розділити запитувану зміну та непрошений рефактор на (безліч) окремих комісій, як зазначають @Useless, @Telastyn та інші, то це найкраще, що ви можете зробити. Ви все одно будете працювати над однією CR, без адміністративних витрат на створення "рефакторингу". Просто тримайте свої зобов'язання невеликими та зосередженими.

Замість того, щоб дати вам кілька порад, як це зробити, я вважаю за краще вказати на набагато більші пояснення (насправді, книги) від фахівця. Таким чином ви зможете дізнатися багато іншого. Читайте « Ефективна робота зі спадковим кодексом» (Майкл Перо) . Ця книга може навчити вас робити рефакторинг, переплетені з функціональними змінами.

Теми, що охоплюються, включають:

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

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

Я теж чудово вірю в Правило Boyscout і Opportunistic Refactoring. Проблема часто полягає в тому, щоб придбати менеджмент на придбання. Рефакторинг поставляється як з ризиком, так і з вартістю. Те, що менеджмент часто не помічає, - це теж технічна заборгованість.

Це людська природа. Ми звикли мати справу з реальними проблемами, не намагаючись їх запобігти. Ми реактивні, а не ініціативні.

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

Незважаючи на те, що багато менеджерів це розуміють, вони несуть відповідальність за зміни у виробничому кодексі. Є політика, яка полегшує залишати достатньо добре в спокої. Часто людина, яка потребує переконливості, насправді вище вашого менеджера, і він просто не хоче битися, щоб отримати ваші "чудові ідеї" у виробництво.

Якщо чесно, ваш менеджер не завжди впевнений, що ваш засіб насправді такий чудовий, як ви вважаєте, що це є. (Зміїна олія?) Існує продаж. Ваша робота допомогти йому побачити вигоду.

Керівництво не поділяє ваші пріоритети. Одягніть шапку управління і побачите очима управління. Ви, швидше за все, знайдете прямий кут. Будьте наполегливі. Ви зробите більше змін, не дозволяючи першій негативній відповіді стримувати вас.

Якщо ви можете розділити запитувану зміну та непрошений рефактор на два окремих запити на зміни, як зазначає @ GlenH7, то це найкраще, що ви можете зробити. Ви тоді не "хлопець, який витрачає час", а "хлопець, який працює вдвічі важче".

Якщо ви часто опиняєтесь у ситуації, що не можете їх розділити, тому що для запитуваної роботи зараз потрібен рефактор, що не має запитів, для компіляції, я б запропонував вам наполягати на тому, щоб мати інструменти для автоматичної перевірки стандартів кодування, використовуючи аргументи, викладені тут (Resharper попередження самостійно може бути хорошим кандидатом, я не знайомий з цим). Ці аргументи справедливі, але є один додатковий, який ви можете використати на свою користь: маючи ці тести, тепер ви покладете обов'язок здавати тести на кожній комісії.

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