Чи вразливі динамічні мови для спритного розвитку?

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

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

Чи важко, якщо не неможливо, переробляти чи (автоматизувати) зворотну інженерію в динамічно набраних мовах? Що реальних проектів розповідає про використання динамічно набраних мов для гнучкої методології?

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

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

З іншого боку, існують статично типізовані мови, які мають по суті ті ж переваги, що й динамічні мови (тобто компактні та зрозумілі - з типами в основному зроблені висновки, але їх дуже багато): Haskell - це, мабуть, провідний приклад, але OCaML / F #, Scala, та інші також в цій категорії. На жаль, оскільки вони менш широко використовуються, ніж найпопулярніші статично набрані мови, вони не мають настільки широкого набору інструментів для них (наприклад, для рефакторингу).

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

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

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

Рефакторинг був винайдений на динамічних мовах. Автоматизовані інструменти рефакторингу були винайдені на динамічних мовах. ІДЕ були винайдені в динамічних мовах. На динамічних мовах було винайдено кілька гнучких методологій.

Я справді не бачу жодної проблеми.

Щоб ми не забули, "Agile" спосіб роботи, який став відомим як Extreme Programming (XP), був створений за проектом Smalltalk (і Smalltalk, безумовно, вважається "динамічною" мовою).

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

На Cargill була розроблена дуже велика програма Smalltalk для підтримки роботи зернових елеваторів та пов'язаної з цим торгової діяльності. Клієнтська програма Smalltalk має 385 вікон та понад 5000 класів. Близько 2000 класів у цій програмі взаємодіяли з раннім (приблизно в 1993 році) рамкою доступу до даних. Рамка динамічно виконувала відображення атрибутів об'єкта в стовпці таблиці даних.

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

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

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

У 17100 змінах було виявлено менше 35 помилок. Усі помилки були швидко усунені за три тижні.

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

Завдання було виконано за 3% від очікуваного часу за допомогою переписати правила. Це поліпшення в 36 разів.

від "Трансформація рівня даних програми" буде Loew-Blosser OOPSLA 2002

Також - "Інструменти для неможливих змін - досвід роботи з інструментом для перетворення великих програм Smalltalk"

Думка ваших принципів звучить для мене правильно .

Сильно набрані мови, такі як C #, є хорошими кандидатами для кодової бази, яка постійно потребує повторного факторингу. В основному більшість інструментів ре-факторингу (наприклад, Resharper, JustCode та ін.) На ринку є дуже ефективними в статично набраних мовах програмування.

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

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

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