Являются ли динамические языки невыгодными для гибкой разработки?

12

Из того, что я прочитал, гибкая разработка часто включает в себя рефакторинг или обратный инжиниринг кода в диаграммы. Конечно, это гораздо больше, но если мы рассмотрим методы, основанные на этих двух методах, являются ли языки с динамической типизацией невыгодными?

Кажется, что статически типизированные языки значительно упростят рефакторинг и реверс-инжиниринг.

Рефакторинг или (автоматизированный) обратный инжиниринг трудны, если не невозможны в динамически типизированных языках? Что в реальных проектах говорят об использовании динамически типизированных языков для гибкой методологии?

agile dynamic-typing static-typing

— Gerenuk
источник

5

Обратный инженерный код в диаграммах? Зачем тебе это делать в Agile?

— CaffGeek

7

Agile не означает «сначала код, потом документ».

— Gort the Robot

@CaffGeek: Некоторые часто рекомендуемые книги предлагают рисовать диаграммы на доске, затем кодировать и, наконец, преобразовывать код в диаграммы для следующего собрания.

— Геренюк

1

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

— Уинстон Эверт

@WinstonEwert - Хороший звонок, я изменил теги dynamic-typingиstatic-typing

— Carson63000

11

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

Но все остальное не равно. Самые популярные динамические языки допускают очень компактный, но понятный код, который, как правило, ускоряет разработку в них и делает логику (которая может измениться в рефакторинге) более легкой для визуального определения. Поэтому, хотя вы можете потерять некоторые относительные преимущества работы на динамическом языке, вы все равно можете выйти вперед, особенно если вы все равно планируете провести рефакторинг вручную.

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

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

— Рекс Керр
источник

Я думаю, что этот ответ лучше всего отвечает на ключевые вопросы вопроса :) Не могли бы вы также рассказать о важности безопасного рефакторинга и реверс-инжиниринга для гибкой разработки? Я предполагал, что это сыграло очень важную роль? Возможно, это меньше, чем я думал, и инструменты для языка динамики достаточно хороши.

— Геренюк

1

@ Геренюк - у меня нет достаточного опыта в области гибкой разработки (особенно в динамических языках), чтобы дать авторитетный ответ - акцентирован ли аспект рефакторинга, оставлен тот же и т. Д.? Имейте в виду, что другие общие аспекты процесса - например, разработка на основе тестирования - могут помочь точно определить, где произошел сбой рефакторинга, и если вы приложите немного больше усилий, скажем, на этапе проектирования, вам может не понадобиться рефакторинг столько же. Я не думаю, что какой-то конкретный метод является ключевым - он держит под рукой полный набор инструментов, часто и совместно используемый.

— Рекс Керр

14

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

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

— Уинстон Эверт
источник

1

А как насчет обратного инжиниринга? Отличается ли Smalltalk от Python в отношении набора текста? Кажется сложной задачей вывести все типы в Python и таким образом определить, какие методы действительно идентичны, а не просто с одинаковыми именами.

— Геренюк

2

Smalltalk не что сильно отличается от Python касаемо печатать. Это является , однако, существенно отличается в зависимости от оснастки . Инструменты и IDE, доступные для Smalltalk, намного лучше, чем те, которые доступны для Python или даже C #, C ++ и Java. Причина, по которой IDE для Python являются плохими, не в том, что Python динамически типизирован, а в том, что, ну, в общем, IDE для Python плохие. Давайте не будем забывать, что IDE, которую мы теперь знаем как Eclipse, когда-то называли VisualAge для Smalltalk. Сообщество Smalltalk имеет 40-летний опыт создания IDE, и они применяют его в Java.

— Йорг Миттаг

@Gerenuk, типография Smalltalk ничем не отличается от python. Другими способами, такими как самоанализ, Smalltalk предоставляет набор функций, более дружественный к рефакторингу. Вывод типа в python потребовал бы работы, но это было сделано, см. Проект PyPy.

— Уинстон Эверт

1

@WinstonEwert «но вы можете выполнить рефакторинг вручную, а динамические языки на самом деле делают это довольно легко» - Нет, ручной рефакторинг не масштабируется. Поддержка инструментов для рефакторинга меняет все, даже если рефакторинг не на 100% автоматический (см.

— Фрагменты примера

1

Почти каждая точка в вашем «динамическом программировании на самом деле облегчает рефакторинг» - сомнительно или не является следствием. Динамическое программирование не означает, что у вас есть более полный набор тестов, просто больший (потому что некоторые вещи требуют тестирования, которое в противном случае было бы статически поймано). Вы не предлагаете никакой поддержки для «рефакторингов, как правило, влияющих на меньшее количество кода» (как дополнение к «проекту все равно меньше», что, вероятно, верно, учитывая текущий набор динамических языков). И «усилия по ручному рефакторингу» кажутся неправильными, если только вы не хотите сказать, что ваш компилятор даже не поможет вам!

— Рекс Керр

8

Рефакторинг был изобретен в динамических языках. Инструменты автоматического рефакторинга были изобретены на динамических языках. IDE были изобретены в динамических языках. Несколько динамичных методологий были изобретены на динамических языках.

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

— Йорг Миттаг
источник

«Smalltalk не сильно отличается от Python в отношении набора текста. Однако он существенно отличается в отношении инструментов». - Может быть, это начинает меняться, см. Jetbrains.com/pycharm/features/index.html

— igouy

3

Чтобы не забывать, «Agile» способ работы, получивший название Extreme Programming (XP), был создан в проекте Smalltalk (и Smalltalk определенно считается «динамическим» языком).

Вот пример промышленного использования инструмента рефакторинга с динамически типизированным языком:

В Cargill было разработано очень большое приложение Smalltalk для поддержки работы элеваторов и связанных с ними операций по торговле товарами. Клиентское приложение Smalltalk имеет 385 окон и более 5000 классов. Около 2000 классов в этом приложении взаимодействовали с ранней (около 1993 года) средой доступа к данным. Среда динамически выполняет сопоставление атрибутов объекта со столбцами таблицы данных.

Анализ показал, что хотя динамический поиск занимал 40% времени выполнения клиента, это было ненужным.

Был разработан новый интерфейс уровня данных, который требовал, чтобы бизнес-класс предоставлял атрибут объекта для сопоставления столбцов в явно закодированном методе. Тестирование показало, что этот интерфейс был на порядок быстрее. Вопрос заключался в том, как изменить 2100 пользователей бизнес-класса на уровне данных.

Разрабатываемое большое приложение не может заморозить код, пока создается и тестируется преобразование интерфейса. Нам пришлось создавать и тестировать преобразования в параллельной ветви репозитория кода из основного потока разработки. Когда преобразование было полностью протестировано, оно было применено к основному потоку кода за одну операцию.

Менее 35 ошибок были обнаружены в 17 100 изменений. Все ошибки были быстро устранены за три недели.

Если бы изменения были внесены вручную, мы предполагаем, что для разработки правил преобразования потребовалось бы 8500 часов по сравнению с 235 часами.

Задача была выполнена за 3% ожидаемого времени с использованием правил перезаписи. Это улучшение в 36 раз.

из «Преобразование прикладного уровня данных» Уилл Лев-Блоссер OOPSLA 2002

Также - «Инструменты для внесения невозможных изменений - опыт работы с инструментом для преобразования больших программ Smalltalk»

— igouy
источник

1

Ваши принципы мысли звучит для меня правильно .

Языки со строгой типизацией, такие как C #, являются хорошими кандидатами на кодовую базу, которая постоянно нуждается в перефакторинге. В основном большинство инструментов повторного факторинга (таких как Resharper, JustCode и т. Д.) На рынке очень эффективны в статически типизированных языках программирования.

Что в реальных проектах говорят об использовании динамически типизированных языков для гибкой методологии?

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

Таким образом, гибкая методология не дает преимуществ статически типизированным или динамическим языкам. Это обеспечивает итеративный подход к созданию надежного приложения.

— Юсубы
источник

4

У динамических языков были инструменты автоматического рефакторинга задолго до того, как C # даже появился, и когда Notepad оставался самой мощной Java IDE.

— Йорг Миттаг

4

Этот ответ совершенно не подтверждается моим опытом. Динамические языки , как правило , быстрее делать вещи , чем более традиционные статически типизированных из них (я получил , чтобы узнать Haskell или ML или что - то подобное когда - то). Они также намного быстрее модифицируются при необходимости, что привело к моему выводу, что Common Lisp был лучшим языком, когда вы не знали, что делаете. Кроме того, как вы думаете, с чего начался рефакторинг?

— Дэвид Торнли

1

почему вы так думаете, например, javascript - это динамический язык, но Re-sharper не выполняет ту же работу, что и в C #. Во-вторых, я НЕ сказал, что «динамические языки работают медленнее».

— Юсубов

От людей, которые принесли вам IntelliJ IDEA - PyCharm - «Рефакторинг переименования позволяет безопасно и мгновенно выполнять глобальные изменения кода. Локальные изменения внутри файла выполняются на месте. Рефакторинг работает в простых проектах Python и Django. Используйте« Представить переменную »/ Field / Constant и Inline Local для улучшения структуры кода в методе, Extract Method для разбиения более длинных методов, Extract Superclass, Push Up, Pull Down и Move для перемещения методов и классов. " jetbrains.com/pycharm/features/index.html

— igouy

@igouy, я имею в виду Resharper и JustCode в своем ответе. Таким образом, это верно для контекста, на который оно ссылается.

— Юсубов