Интересное тематическое исследование по вопросам масштабирования проектов, в которых используется динамический и интерпретируемый язык, можно найти в « Начальной Scala » Дэвида Поллака.
Я начал искать способ выразить код в моем мозгу более простым, более прямым способом. Я нашел Ruby и Rails. Я чувствовал себя освобожденным. Ruby позволил мне выразить концепции гораздо меньшим количеством строк кода. Rails было намного проще в использовании, чем Spring MVC, Hibernate и другие «оптимизированные» веб-фреймворки Java. С помощью Ruby и Rails я получил возможность выразить гораздо больше того, что было в моей голове за более короткий промежуток времени. Это было похоже на освобождение, которое я почувствовал, когда перешел с C ++ на Java ...
Когда мои проекты на Ruby и Rails вышли за рамки нескольких тысяч строк кода, и когда я добавил членов команды в свои проекты, проблемы динамических языков стали очевидными.
Мы потратили больше половины времени написания тестов, и значительная часть роста производительности, которую мы видели, была потеряна при написании тестов . Большинство тестов в Java были бы ненужными, потому что большинство из них были направлены на то, чтобы убедиться, что мы обновили вызывающие программы при рефакторинге кода путем изменения имен методов или количества параметров. Кроме того, я обнаружил, что работая в командах, где между двумя-четырьмя членами команды были умственные способности, дела в Ruby шли хорошо, но, поскольку мы пытались привлечь новых членов в команду, психические связи было трудно передать новым членам команды .
Я отправился на поиски нового языка и среды разработки. Я искал язык, который был бы столь же выразительным, как Ruby, но таким же безопасным и высокопроизводительным, как Java ...
Как видите, основные проблемы в масштабировании проекта для автора оказались в разработке тестов и передаче знаний.
В частности, автор более подробно объясняет различия в написании тестов между динамически и статически типизированными языками в главе 7. В разделе «Ужасно убивая кроликов: лестницы Двемти» автор обсуждает порт Scala конкретного примера Ruby:
Почему Lucky Stiff ... представляет некоторые концепции метапрограммирования Руби в массиве Двемти, в котором кролик сражается с множеством существ. N8han14 обновил пример для работы в Scala ...
По сравнению с кодом Ruby библиотечные части кода Scala были более сложными. Нам пришлось проделать большую работу, чтобы убедиться, что наши типы были правильными. Нам пришлось вручную переписать свойства Creature в классах DupMonster и CreatureCons. Это больше работы, чем method_missing. Нам также пришлось проделать немалую работу, чтобы поддержать неизменность наших существ и оружия.
С другой стороны, результат был намного более мощным, чем версия Ruby. Если бы нам пришлось писать тесты для нашего кода на Ruby, чтобы проверить, в чем нас убеждает компилятор Scala, нам потребовалось бы намного больше строк кода. Например, мы можем быть уверены, что наш Кролик не может владеть Топором. Чтобы получить такую уверенность в Ruby, нам нужно написать тест, который удостоверится, что вызов |^на Rabbit завершится неудачно. Наша версия Scala гарантирует, что этим Существом может использоваться только Оружие, определенное для данного Существа, что потребовало бы много времени отражения в Ruby ...
Чтение выше может заставить задуматься о том, что по мере роста проектов тестовая запись может стать непомерно громоздкой. Это рассуждение было бы неверным, о чем свидетельствуют примеры успешных очень крупных проектов, упомянутых в этом самом вопросе («Python успешно используется для ... YouTube»).
Дело в том, что масштабирование проектов не очень просто. Очень большие, долгоживущие проекты могут «позволить» другой процесс разработки тестов, с комплектами тестов качества продукции, профессиональными командами разработчиков тестов и другими тяжелыми вещами.
Youtube тестовые наборы или набор Java Compatibility уверен , жить другой жизнью , чем тесты в небольшой учебник проекта , как массив Dwemthy в .