Из того, что я прочитал, гибкая разработка часто включает в себя рефакторинг или обратный инжиниринг кода в диаграммы. Конечно, это гораздо больше, но если мы рассмотрим методы, основанные на этих двух методах, являются ли языки с динамической типизацией невыгодными?
Кажется, что статически типизированные языки значительно упростят рефакторинг и реверс-инжиниринг.
Рефакторинг или (автоматизированный) обратный инжиниринг трудны, если не невозможны в динамически типизированных языках? Что в реальных проектах говорят об использовании динамически типизированных языков для гибкой методологии?
agile
dynamic-typing
static-typing
Gerenuk
источник
источник
dynamic-typingиstatic-typingОтветы:
Динамические языки теоретически находятся в невыгодном положении, при прочих равных условиях, потому что они меньше указывают на то, как работает код (каковы ограничения), и, следовательно, меньше рефакторинга может выполняться автоматически, а возникающие проблемы также не могут быть обнаружены автоматически. ,
Но все остальное не равно. Самые популярные динамические языки допускают очень компактный, но понятный код, который, как правило, ускоряет разработку в них и делает логику (которая может измениться в рефакторинге) более легкой для визуального определения. Поэтому, хотя вы можете потерять некоторые относительные преимущества работы на динамическом языке, вы все равно можете выйти вперед, особенно если вы все равно планируете провести рефакторинг вручную.
С другой стороны, существуют статически типизированные языки, обладающие, по существу, теми же преимуществами, что и динамические языки (то есть компактные и понятные - с типами, которые в основном выводятся, но их очень много): возможно, ведущий пример - Haskell, но OCaML / F #, Scala, и другие в этой категории также. К сожалению, поскольку они используются не так интенсивно, как самые популярные языки со статической типизацией, они не имеют столь обширного набора инструментов для них (например, для рефакторинга).
Итак, в итоге, я думаю, вы будете адекватно работать с гибкими методологиями в большинстве языков; Я бы не сказал, что сейчас есть явный победитель, поскольку практика еще не догнала теорию.
источник
Автоматизированный рефакторинг был изобретен в Smalltalk, динамически типизированном языке. Так что нет, нет ничего невозможного в автоматическом рефакторинге на динамически типизированном языке. Насколько это сложно, гораздо больше зависит от других факторов, кроме дисциплины набора текста. C ++ и Java имеют статическую типизацию, но инструменты рефакторинга действительно существуют только для Java. Smalltalk с его самоанализом и простым синтаксисом был действительно хорошим кандидатом для инструментов рефакторинга.
В некотором смысле, динамическая типизация фактически облегчает рефакторинг. Если у вас есть хороший набор тестов, вы можете быть уверены, что ваши рефакторинги ничего не сломали. Динамически типизированная база кода обычно меньше. Кроме того, рефакторинг, как правило, влияет на меньшее количество кода. В целом, усилия по ручному рефакторингу динамической кодовой базы меньше, чем статической кодовой базы.
источник
Рефакторинг был изобретен в динамических языках. Инструменты автоматического рефакторинга были изобретены на динамических языках. IDE были изобретены в динамических языках. Несколько динамичных методологий были изобретены на динамических языках.
Я действительно не вижу никаких проблем.
источник
Чтобы не забывать, «Agile» способ работы, получивший название Extreme Programming (XP), был создан в проекте Smalltalk (и Smalltalk определенно считается «динамическим» языком).
Вот пример промышленного использования инструмента рефакторинга с динамически типизированным языком:
из «Преобразование прикладного уровня данных» Уилл Лев-Блоссер OOPSLA 2002
Также - «Инструменты для внесения невозможных изменений - опыт работы с инструментом для преобразования больших программ Smalltalk»
источник
Ваши принципы мысли звучит для меня правильно .
Языки со строгой типизацией, такие как C #, являются хорошими кандидатами на кодовую базу, которая постоянно нуждается в перефакторинге. В основном большинство инструментов повторного факторинга (таких как Resharper, JustCode и т. Д.) На рынке очень эффективны в статически типизированных языках программирования.
Для команды разработчиков, которая практикует методологию Agile / Scrum, очень полезно (даже критически важно) иметь хороший набор инструментов ре-факторинга под броней. В противном случае, все внезапные изменения в предстоящем спринте могут быть кошмаром, чтобы изменить или изменить дизайн.
Таким образом, гибкая методология не дает преимуществ статически типизированным или динамическим языкам. Это обеспечивает итеративный подход к созданию надежного приложения.
источник