Як ви пояснюєте рефакторинг нетехнічній особі?


52

Як ви вирішите пояснити рефакторинг (та технічну заборгованість) нетехнічній особі (як правило, PHB або замовнику)? ("Що, це обійдеться мені місяць вашої роботи без видимої різниці ?!")

ОНОВЛЕННЯ Дякую за всі відповіді, що наразі є, я думаю, що цей список надасть кілька корисних аналогій, на які ми можемо вказати відповідних людей (хоча редагування посилань на PHB може бути розумним!)


Я не пам'ятаю, як Apple переконувала стільки людей перейти з Леопарда на Снігового Леопарда. Можливо, ціна: на 100 доларів менше, ніж зазвичай на той час.
mouviciel

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

чому це було б мудро?
Луї Ріс

Відповіді:


53

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

Якщо ви часто замінюєте деталі, іноді варто все виправити.

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

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


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

21
@Axidos: "гніздо щурів" - це англійська ідіома, що означає "начебто неможливо відмовити клубок" (у цьому випадку шнурів та кабелів за розважальним центром)
HedgeMage

8
Концептуально його досить добре - потребує "кабелів" після "гнізда щурів"
Мерф

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

3
Якщо хтось не може зв’язатися, покажіть це: google.com/images?q=do+not+touch+any+of+these+wires
Стів S

41

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


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

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

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

21

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

Можливо, підійде аналогія автомобіля: Вам потрібно додати кондиціонер до автомобіля, але він спочатку не був призначений для цього. Вам не тільки потрібно зробити дивний кондиціонер у формі Г, але також потрібно спочатку перемістити деякі інші речі і змінити систему вентиляції.

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


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

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

Отже, коротка відповідь стає: Не кажіть їм! Просто враховуйте час у нових функціях та відповідно.
Джонатан ван де Вен

12

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

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

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

Я, як правило, використовую термін "xxxx борг" як аналогію, коли розмовляю з тим, ким є цільова аудиторія. Наприклад, операційний борг - друкарський верстат, який ми зараз маємо, працює добре, але зупинивши виробництво на один день (або один тиждень) та модернізувавшись до нової машини, ми можемо збільшити випуск продукції на 25%.

РЕДАКТУВАТИ - Ось ще одне питання


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

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

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

4
Це страшна відповідь. (1) Це складніше, ніж технічне пояснення рефакторингу. (2) Це не пояснює "чому" рефакторингу; це пояснює "коли" рефакторингу (тобто: коли це економічно вигідно). А може, я справді просто не розумію цю посаду, а значить, пункт (1).
Томас Едінг

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

8

Весняне прибирання.

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


1
+1: Це найкраща відповідь imo: і майже кожен може зв’язатись. "Ви живете в своєму будинку, речі забруднюються / запилюються / модно - періодично вам потрібно робити глибоку чистку".
Стівен Еверс

7

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

Вам може бути цікаво, чому ми в першу чергу починаємо виглядати як мишоловка:

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

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


6

alt текст

Це трохи більш графічна версія аналогії домашнього кінотеатру.

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

Якщо ви хочете додати ще один прилад, ви можете придбати подовжувач, який буде купувати вас деякий час.

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

1 Інша річ, що ПХБ не стоїть дуже добре: "Що ж, якщо це може статися, то що ти хвилюєшся?"


5

Рефакторинг - це як організація шафи для одягу / ящика для інструментів.

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

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

Так само, як і код. Тим більше, що вона росте з часом.

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


4

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


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

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

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

"Технічне обслуговування коду" звучить так, що ваш код зазнає зносу або звикання. Автомобіль потребує технічного обслуговування, оскільки нормальне використання підкреслює його компоненти, використовує рідину тощо. Додаток не такий - код, що сидить на жорсткому диску, не «старіє» або «не поганий» самостійно.
Dan Ray

Наведу кілька прикладів щодо технічного обслуговування: Проблеми з продуктивністю. Ваш компонент, вся система або додаток написано на VB, і Microsoft перестає його підтримувати. ОС не підтримує технологію, на якій базується ваш код. Питання безпеки. Обслуговування цих питань не додає нових функцій, які може помітити кінцевий користувач, однак вони є критичними для збереження "програми" в живих.
Амір Резай

4

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

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

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

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

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

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

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

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

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

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

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

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

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


3

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

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

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


Але clever == 0так 2 * clever == 0...
Томас Едінг,

3

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

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

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


3

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

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

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

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

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


2

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

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

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

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

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

Ставтесь до свого коду так само.


1
Мені це подобається, але я б змінив це на прибирання кухні. Певний час не готуйте, але згодом все стане краще. PHBs можуть виникнути труднощі , пов'язані з вечірка за часом компанії :)
Яап

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

1

Легко!

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

Отже, у вас є ваш текст, ... сенс буде проходити в будь-якому випадку, але ви хочете, щоб вся справа звучала приємно! Правильно?

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

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

Чию статтю ви запам'ятаєте?


1

Усі аналогії з речами у фізичному світі - як побудова театру - є, ІМО, жахливими.

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

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

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


/ Всі аналогії /? Я категорично не згоден. Вам просто потрібно бути більш креативними. Також не відповідає на питання ОП.
Томас Едінг

@ThomasEding дякую за ваш коментар. Я не погоджуюся з другим моментом: я, власне, відповідаю на питання. Однак я зараз зроблю редагування лише для вас.
Дан Розенстарк

0

Повторний факторинг - це те саме, що чистити щось і давати речі нове місце, щоб «залишитися»

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


0

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

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


1
тож якщо я PHB або клієнт (який збирається заплатити за це зусилля, що рефакторингу), чому я повинен турбуватися? Код працює (з моєї точки зору)
Дан Пішельман,

0

Дайте їм просте математичне рівняння. Наприклад:

Що простіше?

y = x + x

або

y = 2x

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

Найпростіший рефакторинг, який можна зробити, - це перейменування.

doX() { ... }
{
   doX()
}

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

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

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


1
Мені дуже подобається ця аналогія, тому що вона зрозуміла всім і дуже схожа на сам код.
Венкат Д.

Дякую, я навіть опублікував це у своєму блозі trajano.net/2013/05/refactoring-explained
Архімед

0

Малюнок говорить тисячу слів. Наприклад, рефакторинг має два випадки використання:

  • Коли все не робиться правильно з першого разу:

рефакторинг, коли все не робиться правильно з першого разу

  • Коли нудні речі:

рефакторинг, коли справи втомлюють

Список літератури


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

@bdsl Про це йдеться на робочому
місці.se

0

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

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

Підривний? Я не думаю, що так. Розробники програмного забезпечення - професіонали. Наша робота полягає в тому, щоб якомога швидше створити ефективне програмне забезпечення. … Менеджер, керований розкладом, хоче, щоб я робив найшвидший спосіб; як я це роблю - це моя справа. Найшвидший спосіб - це рефактор; тому я рефактор.

(Рефакторинг, Мартін Фаулер, 2000, стор. 61)

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.