Рефакторинг: Це не просто фантазійне слово для очищення коду? [зачинено]

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

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

Рефакторинг старший за пагорби, так що ні, це не щось нове.

І рефакторинг не прибирає. Добре, що може бути, але прибирання не обмежується.

Це коригування архітектури вашої програми (великі чи малі масштаби), зберігаючи поведінку.

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

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

Це незважаючи на те, які зміни в коді внесені, завжди слід проводити свої тести ... про всяк випадок.

Це просто прибирання коду. По суті, програмісти (особливо Мартін Фаулер) зауважили, що вони, як правило, виконують одні й ті ж завдання щоразу, коли прибирають код. Вони визначили та позначали методи прибирання та пов'язані з цим проблеми коду та престо! Народився рефакторинг.

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

Немає ніякої магії рефакторингу; це лише новий набір жаргону для опису старої практики.

Ми робимо три окремі речі в нашій компанії, виділивши час для трьох:

• Рефакторинг: полягає у зміні структури коду, зберігаючи таким чином поведінку.

Приклад: розділення некрасивого та нечитабельного методу на 100 рядків, який робить чотири речі на чотири способи багаторазового використання, по 25 рядків.

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

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

• Забезпечення правил StyleCop / FxCop: полягає у перевірці, чи відповідає код набору за замовчуванням правилам StyleCop або FxCop, а якщо ні, то змініть його, щоб відповідати цим правилам.

Приклад: додавання Culture.Invariantв string.Format(або іншу культуру , яка є більш підходящим).

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

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

Сподіваємось, що багато кращих кроків - малих та великих - дають кращу програму.

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

"Очищення" може означати що завгодно - від "переформатування трохи" до "переписування великих шматок".

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

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

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

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

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

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

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

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

Я б сказав, що ні.

У процесі рефакторингу може бути очищення, але це не суть.

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

DRY - ключовий привід рефакторингу.

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

Всього мої 0,02

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

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

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

Ні. Рефакторинг - це поліпшення структури без зміни поведінки. Рефакторинг у строгому сенсі тягне за собою добру випробувальну дисципліну. Це не обов'язково, коли ви "прибираєте речі".

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

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