Як я можу зробити рефакторинг пріоритетним для моєї команди?

У кодовій базі, з якою я працюю щодня, немає автоматизованих тестів, непослідовних імен та безлічі коментарів на кшталт "Чому це тут?", "Не впевнений, чи потрібно це" або "Цей метод не названий правильним", і код залитий "Журнали змін", незважаючи на те, що ми використовуємо управління джерелами. Досить сказати, наша база даних може використовувати рефакторинг.

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

Як я можу продемонструвати значення рефакторингу таким чином, щоб воно було додане до наших списків завдань? Чи варто це просто рефактор, коли я йду, просячи пробачення, а не дозволу?

"Краще просити прощення, ніж дозволу" - це правда.

Навіщо турбуватися про це? Просто рефактор найстрашніших частин.

Ви вже знаєте, які найдорожчі помилки, правда?

Якщо ви цього не зробите, тоді крок 1 - це позитивно та однозначно визначити найдорожчий, складний код проблеми з помилками.

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

Потім виправте щось із цього списку проблем з високими витратами .

Коли вам доведеться попросити пробачення, ви можете вказати на зниження витрат.

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

Це означає вибрати одне . Напишіть одиничний тест. Виправте це одне. Ви зробили два вдосконалення. (1) написав тест і (2) зафіксував код.

Ітерація.

Дотримуйтесь правила хлопчика-розвідника: залиште кемпінг (код) трохи краще, ніж ви знайшли. Я ніколи не чув, щоб хтось писав за те, щоб зробити невеликі вдосконалення коду, "поки вони там були".

Я прийму, можливо, занадто цинічну точку зору.

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

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

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

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

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

Я намагаюся донести це усвідомлення і змінити ставлення до "моїх" розробників. Щоразу, коли вони запитують мене "коли ми встигнемо рефактор?", Я здивовано і відповідаю: "Ви вже повинні весь час рефакторифікувати!". Єдиний спосіб, на який я вважаю, що ви можете зберегти базу коду здоровою, це триразово:

1. Лише коли-небудь додайте здоровий код.
2. Завжди фіксуйте не дуже здоровий код, як тільки його побачите.
3. Якщо з причин терміну ви не можете зробити 1 або 2, завжди майте список питань "виправити негайно після закінчення строку", і не приймайте жодних виправдань, щоб не працювати через цей список після закінчення цього терміну.

Наступним зауваженням розробників є незмінно "але як ми отримуємо час для цього - у нас немає часу?". Єдина правильна відповідь (знову ж таки IMHO) - "у вас немає часу НЕ робити цього". Якщо ви не збережете кодову базу здоровою, ви побачите, що час повороту стає все довшим і довшим, графіки стають все більш непередбачуваними, помилки стають більш неприємними, а значення стає нижчим.

Найбільша зміна ставлення, яке потрібно здійснити в команді розробників, - це те, що "якість" - це не те, що ви робите в конкретний момент часу ("коли у нас є час на рефактор"), - це те, що вам доведеться робити ВСЕ час.

Нарешті, історія попередження. Якщо натиснути, я заперечу, що це колись було. У компанії, в якій я працював, був давній додаток з великою спадковою базою кодів, що виходила понад 10 років тому. Багато розробників, включаючи мене, вважали, що ця застаріла база коду є поганою або принаймні застарілою, не найсучаснішою. Тож ми успішно лобіювали великий проект рефакторингу, і розпочали проект перезапису, після якого ми вірили, що все буде краще.
Ми довго і наполегливо працювали над тим, щоб реалізовувати майже все по-новому та сучасно, використовуючи нові бібліотеки, нові мовні функції. Під кінець ми доклали великі зусилля, щоб об'єднати все, щоб дозволити новий випуск давньої програми з новою та покращеною базою коду.
Як очікувалося, новий випуск мав деякі проблеми із прорізуванням зубів, через нові бібліотеки, з якими ми ще не були настільки знайомі, та деякі взаємодії в нашому коді, які ми не передбачували. Однак нам нарешті вдалося домогтися випуску до того ж стандарту, що і в попередніх релізах, і вийшли з дверей. Ми полегшено зітхнули на наш «успіх». Потім підгрупа розробників повернулася до управління, попросивши новий проект рефакторингу, оскільки наш новий код був не зовсім срібною кулею, яку вони очікували, і вони побачили деякі можливості повністю переписати деякі речі ...

Мораль історії: часто речі не є настільки зламаними, як здається, і "починаючи з початку" зазвичай означає, що ви будете торгувати відомим набором питань, як мінімум, як волохатий, невідомий набір питань. Рефактор по черзі!

Хтось одного разу сказав мені, що коли я йду на співбесіду, я не повинен забувати, що я також беру інтерв’ю в компанію. Це місце, в якому я хочу працювати? Чи роблять вони огляди коду? Чи мають автоматизовані тести інтеграції? Одиничні тести? Що вони думають про парне програмування? Особисто я знайшов би іншу роботу, і цього разу не забудьте задати деякі питання.

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

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

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

Якби мені довелося запровадити одну практику, щоб покращити справи в такому контексті, це були б огляди коду. Огляди коду є

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

Ви не повинні робити огляди коду систематично, лише спочатку виконуючи великі / складні частини коду.

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

Ось що я роблю в таких ситуаціях (за 15 років моєї кар’єри як розробника я стикався з таким кодом майже кожен день)

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

Керівництво ніколи не відводить часу на пере-факторинг коду (у них ніколи не вистачає ресурсів!), Тому робити це повільно та неухильно - це правильний підхід.

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

"Чиста робоча площадка - це безпечна та продуктивна робоча площадка", і кожен внесок у безлад поєднує безлад у експоненціальному, а не лінійному режимі.

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

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

Ведучий програмного забезпечення та команда виділяють час команди

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

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

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

Ранній вибір проектів створить загальний цикл рефакторингу

Обслуговування програмного забезпечення важке. Удвічі важко, якщо інші в організації роблять вибір за ваш рахунок. Це неправильно, але це не нове. До нього звернувся Баррі Бум, який є одним із наших великих авторів програмного забезпечення, який висуває модель управління, яку він характеризує як Теорію В.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Часто розробникам програмного забезпечення забивають виробляти за підходом до управління теорією X, який говорить про те, що працівники в основному ледачі і не будуть працювати, якщо їх не піддають. Бум підсумовує та протиставляє запропоновану модель наступним чином:

"Замість того, щоб характеризувати менеджера як самодержавника (Теорія X), тренера (Теорія Y) або фасилітатора (Теорія Z), Теорія W характеризує головну роль менеджера як переговорника між його різними округами та упаковкою проектних рішень. з умовами виграшу для всіх сторін. Крім цього, менеджер - це також постановник цілей, моніторинг прогресу у досягненні цілей та активіст у пошуку щоденних конфліктів виграшних чи програшних проектів, протистояння їм, і змінюючи їх на безпрограшні ситуації ".

Швидкий і брудний часто просто брудний

Бум продовжує зазначити причину, через яку розробники в службі технічного обслуговування так жалюгідні.

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

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

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

Реконструкція не підлягає переговорам

Не відступайте від своєї ролі менеджера програмного забезпечення. Ви повинні мати повноваження та розсуд використовувати час своєї команди для вдосконалення процесів та продуктів. У цій ролі вам може знадобитися узгодити свій вибір, щоб зробити вашу команду більш професійною. Однак, що стосується процесу, не домовляйтеся з маркетингом, тому що, на мій досвід, це програча гра. Переговори з інженерним управлінням. Це показує, що у вас є зір. Створення професійної команди програмного забезпечення - це розширення їх ролі, і набагато більше шансів сприймати як безпрограшний.

Ви завжди могли просто зачекати. Врешті-решт, команда пропустить достатньо строків та випустить програмне забезпечення, що не вистачає помилок, що керівництво кине руки і скаже, що від Бога щось краще зміниться!

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

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

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

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

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

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

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

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

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

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

Ваша основна проблема полягає в тому, що коди не отримують достатньої видимості.

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

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

Коли якість коду буде помітна всім (особливо лідеру команди та начальнику), і контроль версій та тести блоку є для того, щоб мати спину ... люди почувають себе заохоченими до рефактора.

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

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

Проведіть зустріч та визначте стандартні стандарти кодування.

Введіть основні правила, якими ви користуєтесь:

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

Щоразу, коли виправлена ​​помилка, потрібно додати автоматизовані тести, щоб довести, що клас працює (не лише фіксований код).

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

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

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

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

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

Crap код частіше, ніж не надто дорого виправити. Без автоматичних регресійних тестів, вартість тестування реконструйованого коду надзвичайно висока.

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

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

Як не дивно ніхто про це не згадує:

Щоб речі стали пріоритетними, зробіть їх легкими: Отримайте хороший інструмент рефакторингу.

Є чудові інструменти для рефакторингу (принаймні для .NET afaik). О, і не забудьте заздалегідь написати одиничні тести (як уже вказували інші).

Удачі!