Коли допустимо НЕ виправляти зламані вікна?

Що стосується зламаних вікон , чи є час, коли рефакторинг краще залишити для майбутньої діяльності?

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

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

"Зробіть так, щоб вона працювала краще" .

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

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

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

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

У мене складається враження, що багато людей схильні плутати визначення для Refactoring та Re-Engineering . Два терміни описують стратегії управління дуже різними ситуаціями. Якщо ви хочете перепрофілюватися, ви берете на себе зобов’язання зробити кардинальні зміни, які змінять поведінку системи. Це призведе до недійсності деяких тестів, а також вимагатиме нових тестів. Коли ви перебуваєте в Refactor, ви гарантуєте, що система продовжує точно вести себетак само, як це було до зміни, однак ви також гарантуєте, що ваш код матиме довговічність і що його буде легше підтримувати з часом. Ви не «сутенерствуєте» зі своїм кодом за пекло, ви дотримуєтесь професійного стандарту чистого коду, який знизить ризик виходу з ладу, і забезпечить, щоб ваш код залишався приємним для роботи та професійного стандарту .

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

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

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

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

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

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

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

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

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

Редагувати: Я прочитав цікаву статтю про підтримку графіків критичної інфраструктури. Суть у тому, що рух відходить від рутинного технічного обслуговування (рефактора) до ремонту при необхідності (виправлення помилок). Основна відмінність полягає в рівнях моніторингу - наприклад, атомна електростанція проводить моніторинг дуже детально, і визначає їх, коли вони "зламані", але задовго до виходу з ладу. Що було виявлено, це те, що встановлення на схему vzdrževanja не тільки коштує більше, але й менш надійне через відключення, викликані програмою vzdržece. Аналогічна ідея потрібна і для програмного забезпечення - рефактора біт, який збирається зламати - про який можна дізнатися лише за допомогою вимірювання.

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

Ситуації, де це відбувається, можуть бути:

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

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

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

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

І якщо альтернативи не завжди добре, але коли ми це виправимо?

Тому що це мало б майже, майже, майже завжди бути коли , ні, якщо .

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

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

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

На закінчення, так, прийнятно іноді залишати розбиті вікна, як і прийнятно просити кредит ... просто пам’ятайте, що вам справді доведеться за це заплатити в майбутньому. І в майбутньому час на це, швидше за все, буде не настільки більшим, ніж зараз у вас.

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

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

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

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

Чи варто того, головним чином залежить від вашого менеджера.

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

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

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

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

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

Однак, якщо ви говорите про робочий код, який переосмислюється, я б врахував наступне:

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

• Якщо повторний факторинг негативно вплине на прибутковість бізнесу, його слід перепланувати.

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

• Ви завжди знайдете кращий спосіб щось зробити. Це природний процес, і дуже важливо вміти провести лінію.

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

Щодо "зламаних вікон": цей термін я вперше почув у контексті розробки програмного забезпечення, приблизно 10 років тому. Але в той час його використовували для опису дозволених тестів , що не працювали . Це описував сценарій, коли у людей виникає спокуса не виправляти тести зламаних одиниць, тому що здається більш доцільним просто пам’ятати, які тести «добре помиляються», а не виправляти зламані тести (які були дійсно зламані через інтерфейс або вимоги зміни, наприклад).

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

Якщо його дійсно зламано, то це слід виправити.

Але чи справді це зламано? Ви впевнені, що не просто рівняєте "не симпатичне" на зламане.

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

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

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

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

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

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

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